The Infra Pod - Why do we need a functional package manager like Nix? Chat with Ron at Flox

Episode Date: July 8, 2024

Ian and Tim sat down with Ron (CEO of Flox, Nix foundation chair) to talk about the origins of Nix (functional package manager for Unix-like systems) and the adoption story so far, what are Flox doing to bring adoption to the masses.

Hey, welcome back to our yet another Infra Deep Dive. This is Tim from SMBC and let's go, Ian. This is Ian Livingstone, currently trying to turn Snyk into a platform. It's been quite the journey. And I'm happy and excited to be joined by Ron Afroni from Flox, CEO. Ron, tell us about yourself. Definitely. A little bit about myself. I started off as a

software engineer, went into startups, then led Facebook's developer products for a bit of time before I realized that we're doing everything wrong. Stumbled across a co-founder and then obviously went into the world of Nix and started building Flock. So that's like the really short version of it, but happy to dig deeper if we wanted to. Amazing. So, you know, I think that the first and foremost question is like, what was the problem you had when you stumbled upon Next? You're like, oh, this is interesting.

What was the problem you're actually trying to solve? What was that pain? I think that's a really good question because I can also probably share the two sides of it, right? One side is my purview coming in, trying to build a platform called Developer On Demand inside of Facebook, where I was trying to, me and a huge team were trying to kind of take iOS build times and get them from like 45 minutes to seconds. And what that meant for me versus what it meant for my co-founder who actually started bringing Nix to its first enterprise deployment back in 2017. So there's like two timelines here. From my perspective,

we were trying to, like I said, replicate like iOS tool chains and replicate developer environments in the cloud in order to speed things up and then hook up local developer experiences as a front end. And as we were doing that, there was really, there was this day that we were jotting down the developer flow. What does it mean to spin up a developer environment? And what needs to go into it in order for us to go and then replicate it, right? Very product-y, very like, let's draw it on a whiteboard just so we understand and don't miss anything. And I had this, I guess,

YouTube-esque moment where this diagram on the whiteboard was just going on and on and on about all the steps a developer has to do in order to set up this perfect developer environment that we wanted to recreate on the cloud so nothing is missing. And that just blew my mind to see how far we've extended beyond, let's just get coding because that's what's important let's be you know creative let's make magic happen with the ones and zeros two we're now spending a shit ton of time trying to define just this place so we can even get started and that for me created this notion of okay i have to go look and see if there's something better out there and that's what brought me to Nix. Interestingly enough, in parallel,

my now co-founder, Michael, who was the head of build and release engineering for a huge fund called D.E. Shaw out of New York, he brought it into the firm because he stumbled upon similar issues that extended further. So for him, it was about, how does this $70 billion firm

not make mistakes in the software lifecycle? Because their mistake is millions, kajillions of dollars and obviously has a huge impact. And for him, it was about how do we create a development platform that can span into production that is reproducible, reliable, and secure. And that's what brought him into Nix and also what brought him to bring Nix into the firm back in 2017. What then happened, just a little bit about the origin story, is that Nix wasn't very usable inside of an enterprise context.

And he spun up a team and they created this initial layer just to make it accessible to the developers in the ecosystem. And that layer actually became Phlox and what Phlox is today. But that was kind of the origin story of what even got us to the place of looking for something where the principles are different. Amazing. And so for those that don't know, which is probably a lot of people, because Nix is so relatively like, it's like a bubbling stream in the background of a crazy concert. What is Nix? Like, what is this magical serum you found and are now trying to democratize? Yeah, definitely.

So I'll start off by saying that the first NixCon I did right after COVID, the first thing I actually put on the deck was the InfraMap. And we talked about how Nix is everything and everywhere. So just in the constraint of time, I'm not going to talk about how Nix is everywhere and everything. I'll talk about what I think is the most beautiful aspects of Nix. And I'm sure others will, some will agree, some will have more definitions for it. So a little bit about the history. Nix was started by Ilko 22 years ago now, almost 23 years ago, as a PhD thesis. He came out back then and said, there's a better way to build software, and there's a better way to manage packages,

and he started building this ecosystem. Fast forward to today, Nix is the largest open-source package repository in the world. It's a universal package repository, and it's a cross-platform one. And it also has a unique data structure that allows a lot of other benefits, which we can also talk about a bit later. And why does that matter? It matters because it's the first instance where you can actually pull different packages from different languages from different os's all natively just with one consistent set in the center of it now nix on top of that has the nix language and on top of that there's nix os but the main values that i see coming out of nix

are one the package repository so you can use nix as that universal package manager that crosses across the ecosystem that already creates a lot of unification for the SDLC. The next thing is that Nix allows you to actually have perfect caching and allows you to actually pretty much never rebuild anything twice. And the last thing is kind of on the security side where nix is fully deterministic immutable meaning that when you go and take a package from nix you know exactly the build and runtime dependency graph of it recursively all the way down to libc you know what went into it what were the build instructions and you have an actual checksum that defines that for you. So you never get anything sneaking into that build at any point in the lifecycle

when you're using something from Nix. And so I think most of us, maybe I'll say just developers in general, depending on which world you live in, you may have heard of Nix, you may have tried Nix, but the world of actually adopting Nix, it really depends on where and how you got into the developer ecosystem of the world.

Maybe you can talk about like, okay, how does the adoption of Nix really started to happen? And where do you see the adoption of Nix is starting to grow, right? Because I feel like Nix is one of those tools I feel like has so much power, but for one or another reason, I think the adoption hasn't like fully exploded everywhere yet,

but I feel like this is a time where it's actually starting to happen. So just really curious, like what do you see? Like why did people start using Nix instead of other tools first? And why do you see people, other people are falling sweet now? Yeah, definitely. So I think there's two main forcing functions there. One side of it is just, it's just the world just the world. If you look at software complexity over the last 20 years or since its inception, as humans, we always make things more complex, right? We make things that are better, stronger, but they're more complex.

And the world of software development is just also getting even more fragmented. So you have complexity and fragmentation kind of coming together. And the thing there is that the fragmentation and complexity is coming from, we have so many dependencies now. Open source is the shit, right? It's like more and more software is out there, more and more software you're based on, more and more software you never built. If you go 20 years back to IBM or 40 years back to IBM, you're like, this spaghetti code was built on internal spaghetti code was built on internal spaghetti code. And this person that worked for us, you know, five years ago is still here. And we can always ask him a question. Whereas today, it's distributed, it's everywhere. And I think

that's great. That's magical. But it also just means that it's much, much harder to get things together into an actual, actually like get developing. And I think that's where the use case of yes, Nix was here 20 years ago but it wasn't complex enough to go through the sharp edges of it in order to get all of these like wins around reproducibility and instant developer environments and all that beauty whereas now we're starting to see that and we're seeing that also being catapulted by ai right more code more developers just more stuff to. On the other side of it, in terms of adoption, I think we've started to see a lot of industries that are inherently more complex, like hardware, AI, deep tech, where from the get-go, you have to do things that just are not necessarily easy to do with incumbents like containers or other solutions that you have in the mix. And folks are effectively looking for solutions outside of it.

Now, the bottom line is I think that Nix was also very inaccessible for a long time. And it's still, you know, this is why Phlox exists, to make it accessible, to bring it to work. But I think that was kind of another forcing function of it. Like, do you want to learn functional programming? Do you want to learn the Nix language? Do you want to go through a Nix build process that has its own intrinsic qualities to it? So the value to complexity ratio, I think, is starting to equalize, and

ideally, the value is starting to go beyond it. What do you think the tipping point has been? Have you seen any specific moments in time? Oftentimes like i'll give you an example from sneak i guess you know page talk where but like the fun little problem is like open source vulnerabilities and there's like log4j is an example like a black friday event that occurs and every everyone wakes up and it's like oh my god we all got to have like a dependency scanning for our vulnerabilities and everyone buys it right like i'm curious like in the next ecosystem i mean there's definitely been like i look at twitter i go to github and i look at you know

there's lots of like nix files that are now hanging out in repos and people are talking about nix like was there like a defining moment that's kind of bringing nix to the forefront of people's mind or is it just been this slow trickle of like awareness slowly growing so you know i obviously bias you always want to attribute to like flocks being around for a few years and pushing kind of the edge of usability of Nix powered principles and all that beauty. I also

sit on the Nixos Foundation board and with my Nixos Foundation hat, I think it's a mix of really two things, right? It's like the industry needs that we talked about that are just catapulting year over year and the complexity of them. People are looking for reproducibility, are looking for different principles to base their software stack on so that they're not kind of building on shaky ground. And this whole anecdote that I have there is kind of like software development and software

developer tooling in the SDLC. It's like building a building, but each floor we add on top every few years, right? And kind of you bring in a different contractor to do that second floor, and they're not really sure what we put in the first floor. So they kind of rebuild that floor on top because they know the problems, but not necessarily all the intrinsic items in the baseline of it. Where I see Nix coming in, it's like saying, okay, let's rebuild the building. Now that we know, you know, what kind of ground we have and what conditions we're trying to meet and who's going to building. Now that we know what kind of ground we have and what conditions we're trying to meet and who's going to live here and why we're going to use this

building because we've been doing software for so long, let's now build the building with all of this knowledge and let's make it fit the use cases of software development today. So that's on one side. I think the other side is just very obvious, high-profile success stories. You have a lot of high-profile folks who've converted to Nix or have been using Nix. There's individuals like Mitchell from HashiCorp, who's just amazing and also gives a lot of feedback. And I think that's been kind of swaying a lot of developers. There's high-profile success stories inside of huge companies. So D.E. Shaw, where Flux originated from,

Google just announced on their keynote that the entire IDX project is Nix-based, and so is projects like Looker. So you're starting to see, we call it Nix in the wild, we have this whole series around it, where you're starting to see Nix in the wild, right? And starting to go from a, oh, there's that group of people at the back of the concert and they kind of look scary. You know, should I even approach them? Everyone's kind of like chirping about it and mentioning it or exploring it to some level. I would say the inflection point in my eyes started happening about a year, a year and a half ago, where you started seeing that grow. And that's what I've been seeing.

I'm curious, like you mentioned earlier, that there's some really interesting technical things going under the hood. Help us understand, like, what's the secret sauce of Nix that, like, actually makes it work? Like, there have been lots of attempts in my career at trying to create reproducible local environments or reproducible builds from, like, all the way up the stack of, like, the entire environment and have it be encapsulated. I mean, I've used like everything

to try to do it like bash scripts, you know, and that falls apart. And then you bring in something like Ansible and that falls apart. What is it? What's the secret sauce of Nix that like on a technical level that actually enables it to solve this problem categorically in a way that hasn't been solved before? I'll start with what I think is the bottom line secret sauce. And then we can go into like the practicalities of, okay, well, how does that even happen? I think the bottom line secret sauce is if you actually want reproducibility, you actually want 100% visibility into your entire dependency graph. You want the security, you want the build wins, you want the caching wins, you want all these amazing things. You have to take into account that we as humans, like we said earlier, have created some of the most complex scenarios in

the world in order to build software today. And you can't get all that if you don't have, you know, this is like a very boring way to look at it, but like an entire phone book of the world's history of software in your backseat. How are you going to get reproducibility? If you don't know five layers down, what the dependencies are of this open source project that someone out in Montana is handling, right?

And how are you going to know how that dependency graph looks like if you don't call that person in Montana and then be like, yo, what's, what are you dependent on? And I think what happened here is that when Nix started 20 something years ago, the core concept was to create Nix packages. And Nix packages was supposed to serve that. And it was a crazy idea that if I think if you would have pitched it to many people 20 years ago, they'd be like, there's no chance you can do it. But that's what ended up happening

with like the open source community. Over 20 years, Nix today is kind of like your phone book of software since 20 years ago. And now if you want to technically go and create this reproducibility or create this visibility or do all these awesome things, you have the phone book. You have the data. Now you can get technical about it. And I think a lot of attempts have figured out the technical side, but there's just like a human aspect of effort. Maybe in the future, AI gets into the mix there, but there had to be humans involved over decades to build that catalog out so that we can base it on it. So I think what the main secret sauce is Nix packages. 6,500 monthly active contributors today are contributing to Nix packages. You know, 6,500 monthly active contributors today are contributing

to Nix packages. And that's been going on, like I said, for, you know, scaling up, but for 20 years. So that's one. I think that the technical side, which I think a lot of people will find maybe not as like far-fetched, and there's many, so I'll just name the ones that I find very unique. One is that everything inside of Nix is a package. I think this is also what happened and helped Nix packages grow to this extent. It's like everything is a package. The things you find to be

obviously a package are packages, but so are your environment. So are your like everything is a package inside of the Nix ecosystem, which allows us to create this bigger phone book concept of everything is a software universe.

That's one. I think two, it's a tree-based data structure. So when you have this node and you add a node into it, if it's a package or whatever it is, you lock it in, it becomes immutable. You can't change it. And if you want to reuse it, you can go take it out and use it. And it has all of its dependencies, right? But then if something becomes dependent on it, that thing doesn't change. It stays there. So you actually have the framework to create a sustainable environment for us to continuously

have these concepts that we called out earlier. It's a great sort of like introduction and sort of like overview about the mixed beauty of things. But as you mentioned, the biggest adoption hurdle so far seems like it's complexity. And complexity is difficult because a lot of people doesn't like to get overcoming complexity easily.

And I always feel like the analogy is similar to some degree of Docker where before Docker exists, everybody have to use like LXC and all these other things. You know, you have to be a joy and user or something like that nature, right? To even have a taste of what it feels like. And once you understand the power, you know, and you kind of have got used to that usability side.

So let me talk about what has been the hardest things for people to adopt Nix so far. Like what kind of complexity is really stopping people? And what are things that, you know, you mentioned Phlox is here to help solve it. Like what are things Phlox is doing to help solve this so that everybody can start to use the power of Nix? Yeah, definitely.

So I think first of all, Nix has been around for a long time and it's a super cutting edge technology. And again, putting my Nixos Foundation board hat on, Nix is supposed to be a greenfield of building all the craziest, wildest dreams you have with a stack with these types of software principles.

Right? So it's like just in the latest NixCon, we had Nix in satellites and Nix in particle accelerators and all these flows that are insanely genius. But obviously the average, the regular developer is not going to use that flow because they have low latency, lag, blah, blah, blah, blah, blah. And Nix is uniquely positioned to solve that.

And the reason I'm saying that is because imagine you have 20 years of these flows being encouraged to be built into the Nix ecosystem. And we'll keep being encouraged to build into the Nix ecosystem because we're literally building a different principle of software development. So one, when you're coming in as a developer into Nix, there's 20 ways to do one thing. And each way is valid, right? It gives you an optimization for a specific niche additional use case on top of the regular SDLC. And I think that created kind of this decision fatigue or this risk, right? When I give you Docker, it's like if you want to do something in Docker, you usually have one or two ways to do it. So if you choose one and it doesn't work, you move to the second. In Nix, because you have so many ways to do a single thing,

when you just go to native Nix as a developer that's trying to deliver something inside of a company or an enterprise, you might fall or stumble across the incorrect way. And therefore, that might be a judgment on your call rather than a judgment on the product itself. So there, for instance, like on the flock side, there's just one golden path. We've taken this all for you and we've condensed it to like,

this is what 95% of engineers working inside of an enterprise would want to do. And this is the flow that we're going to give you just perfect, delightful experience across it from A to Z. With that said, we still allow you to off-road because we want you to go into Nix. We want you to go, if you have an edge

case and you need to go into that beauty of it, go there, do that. The second thing about Nix is it's never built for the enterprise use case. Nix at its core, I think, exemplifies a lot of what open source means. Everything is open. Everything is visible. Everything is recursively open all the way down to your libc. So whatever you're using has to be in that structure. And Nix forces you to be in that structure. Now you're an enterprise. You have proprietary code. How do you get it in there? So there's just some basic functionality. Well, not basic. They're complex, but there's functionality that enterprises need in order to do that adoption motion when you come into it. And I think the third thing, which is kind of overarching, right, is it's complex. It's a different paradigm, right?

We're used to writing Python or we're used to writing, you know, some version of C or Go or something like that. Here we're coming and saying, first of all, it's a functional programming language. It's also a functional build. Everything is deterministic, meaning that you have to kind of have that switch in mindset where these functions, when you put an input, a specific input, it's going to come out the same specific output every single time, which is not something that we're used to at all. And that's one example. The second example is, for instance, when you want to go into the build phase with Nix, you have to write a Nix expression.

You have to know the Nix language. You have to just build that all out. And that is just not something that we're familiar with, or most developers are familiar with at all. One of the questions I have about Nix is, you know, you mentioned there's like 65,000 contributors to Nix packages. 6,500, yeah.

6,500, okay. I mean, still, that's a lot of people. What's the quality distribution of all these Nix packages in the open source ecosystem like? Is there a couple of really great packages with a long tail? Is the Nix ecosystem similar to PIP or NPM where great packages rise and those become the default? What's the ecosystem like?

And is there anything that Nix gives you to help you figure out, or Phlox, give you to help you figure out or flocks give you to help you figure out like which packages you should use over others? Yeah, so I think that's a great question. The ecosystem today is kind of resembling of probably what you would obviously imagine, right? It's thousands of contributors working on packaging and adding them all the time. What's beautiful about it, though, is once you've added a package and it works, it's locked in. And you can always go back to it. So even if the support for that package ends at some point, and just like any other package manager, you would always be able to go back to that package that was supported and was working. And you kind of have that as the

best practice for that package set. But just like every other ecosystem, we have languages that are much more supported or ecosystems that are much more supported within this and ecosystems that are less nourished or less supported just because of the usage right now. And I'm seeing a lot of this come in just from baseline use cases. So when a new company or a new project comes in and they're starting to base their things on Nix,

the first thing they usually do is they scour Nix packages, they get everything they need in place, and then they add the 5% that might be missing for them. But again, the beauty of that, that 5% then is added for everyone. We're kind of like trying to support this amazing effort by a few contributors in Nix to start adding much more Windows support into it. Because Nix is just natively known to be extremely well run on anything Linux based and anything Mac based, but not so much on Windows. And is there like an effort in the community to solve the Windows compatibility stuff? So we're starting that right now. It's being started right now. There's a project called Limnix with Joaquin and Phlox is trying to kind of like fund and help in. And also from the Nixos Foundation, we're trying to get into it. But that's kind of the ecosystem. To your second question about verifying like which packages to use, then there Phlox is working on solutions for that.

And that's kind of one of the things where actually I don't know when we'll air this. It might actually be out by the time we air this because it's coming out very, very soon. You're going to be able to actually have the first instance where you have a Phlox catalog and you'd be able to pull any type of version from any type of package within the Nix ecosystem, which will then allow Phlox to also then recommend things based on that.

Right now with Nix, you usually almost always have to pull latest unless you do some Nix magic behind the scenes. And I think any toolings gaining wide adoption, I feel like there's a couple of things. One, the complexity has to be reduced a lot.

One is, like you mentioned, the ecosystem has to be pushed. But oftentimes One is, like you mentioned, the ecosystem has to be pushed. But oftentimes, I feel like what Docker did amazingly was probably Docker images and files and all that kind of stuff. The ability to just be able to build something so uniquely simple, and the abstraction of the layers and all that stuff,

that never existed in LXC before. Everybody basically treated almost like a VM, almost like a VM virtual, almost like a hypervisor replacement. But that really beautiful thing to kind of take all your data automatically and build something really simple was really magical.

So the push and pull plus the run makes the whole thing so complete. Like, is there something like that nature where Nix can be coupled with some other changes that makes the adoption goes much more wider? And maybe because of just other trends of whatever, maybe AI stuff or some other new trends that people are looking for something much more simple. I'm just wondering, like, what do you think beyond the current Nix world, can we bundle something that even has a wider hole for everyone to adopt this quicker yeah so again this is like one of the main things we're doing at flocks one of the things we're

doing as flocks is that we've created like this flocks environment file that's totally toml based like you know how it works it's very common kind of a flow to it and what you're able to do now is you're able to fluxify your repos and create this full flux environment files super simply, while also we're starting to fluxify other repos just externally. And for instance, you'll be able to go to GitHub today, and I think there's now a few of them, but you'll be able to go to GitHub, look for flux, and I think there's now a few of them, but you'll be able to go to GitHub, look for flocks, and see which repositories have a flocks environment as an installation method. And instead of going through a readme, instead of doing anything, you would just literally type

one command. And then you're set up, you're running, it's fully isolated on your local machine. We're playing around now even with hardware acceleration from some of the AI use cases, because we're able to run on the machine without any abstraction on top of it. So I think to your point, giving these environments that are pre-configured and you have everything you need is like a great on-ramp point for specific ecosystems of developers to just get started. Awesome. Well, I think let's take this opportunity to come move into the spicy future section of our pod. Spicy futures. Ron, I think you're ready. Tell us what you think is going to happen in the next,

let's just put it in some timeframe, like two to three years, well, maybe three to four years that most people don't believe in yet. Tell us your spicy hot takes, sir. I mean, just listening to this might have been a lot of hints about my spicy, very biased hot take would have been here, or is. And I mean, bottom line, I think we're going to move from

peeking at these concepts of like, why should I care about reproducibility and determinism and these things in software development, to we need that in order to actually operate at the scale that software is going. Right? I mean, we're seeing that happen live in front of us. It's just like the latest GitHub metrics on copilot usage. There's, I don't know, from 20 million engineers in the world, we're now potentially moving to having 100 million engineers in the world. And there's like, complexity around AI and all these other edge cases. I think we're going to start expecting and asking our stacks to be reproducible and deterministic. And the reason we're going to

be doing that is because we're going to understand, and that's going to be, I think, the shift, we're going to understand that we just resolve a lot of these problems that we've been trying to patch over the last 10 years. One of them being the build side, where you shouldn't ever rebuild anything twice. The other one being that you should have full visibility into your software stack. Software supply chain security, we didn't even touch on that, but that is a solved problem when you do security by constructions or when you know that you're building from the ground up and what went into that build purely, right?

So I think those are some of the things that we're going to see change over the next two to three years where a lot of products, a lot of platforms, a lot of projects are going to inherently start with, how do I base my thing on these types of principles, whether it's on Nix, Phlox, anything else, maybe something new comes up by then, so that I can be the fastest, best project for my users and my customers. Where do you think Phlox and Nix in general, how does it fit into this broader supply chain security story? There's a lot of focus on, for good reason, on securing your package supply chain.

And there's been discussions with the folks from ChainGuard around hermetic builds and the ability to highly reproduce hermetic builds where all the artifacts are signed and what's produced is signed to the full chain. Where do you see that going over the next number of years? And then I'm curious to understand, where do you think Nix and Flux fit into that equation as well?

So I think this is just another problem that we kind of created because of the complexity side. Again, open source usage, dependencies, everything is going crazy and people and folks with bad intent are finding ways to kind of poke holes in the supply chain.

And now we're like, okay, we care about that. We don't want that to happen, like for Jane, all of those other examples. And what's happening is that we're looking for ways to solidify, secure, or somehow lock in our supply chain. What we're seeing today is that we're saying, what is good enough, right? We're saying, maybe we go two layers down, maybe we go three layers down, and that should be good enough. But like, there's probably 10, 15,

20 more layers beneath that. So I think software supply chain is going to grow, right? There's new resolutions coming off from the EU, from the US. We want to secure these attack vectors and make sure that no one can take advantage of them. I think the most recent one was kind of crazy, right? Where like one of the package maintainers put in a backdoor and it was wild.

Now with Nix and Phlox, imagine that technically can never happen. Because once that package gets set, it's locked in, it has the checksum, you know exactly what went in to make that build happen. And if someone tries to push in a backdoor or do some supply chain attack, that entire checksum changes. You're actually pulling from, it might be the same version written at the top nicely, but Nix will not allow you to have the same checksum. So that hash will be a different hash because we know exactly what built it all the way down to libc so someone was running a side runner on libc you know 16 layers down there will be a digit that changes and you'd be able to flag that or just not use it right and then you get all these magics of like

automatic rollbacks and things like that but i think that's where flocks and nicks comes into play where we say hey come build on top of us and once come build on top of us. And once you build on top of us, one of the benefits you get is there's so much like that visibility, the S-bombs into the supply chain. And then we partner with potentially providers like Snyk for signing, and we make sure that everything is good on that end. We didn't actually talk that much about the security side, but obviously there's a huge benefit if you have really able to pin not just your typical dependencies but all the dependencies other dependencies like i think that's the beauty of nix you're really pinning so many things down to like the deepest layers and i think actually most people don't even realize

that's something that has a huge surface area for folks right and what's beautiful about that is like for folks listening to this you what's beautiful about that is like, for folks listening to this, you don't need to actually be worried about, oh my goodness, 16 layers, do I need to care about that? You don't, because every few layers, there's going to be a package that's secure. And because someone made that package secure,

you know, the 10 layers below that are also secure. So you kind of only come in and you're like, okay, up until there, it's kind of like a crowd effort to make a secure software supply chain. I think security is really one big motivation for larger companies, why they want to help getting supply chain in, why supply chain is such a big deal these days, is open source being used everywhere. And I feel like it's mostly larger companies really have to like lock them down. All the individual developers might think about it, but may not think of it as much as speed, usability, you know, this thing is fun and easier to use than anything else, right? So there's going to be like a lot of like both sides asking for things for you. But I imagine to get Phlox and Nix

being used much more widely is probably a big goal, right? And so that's why Phloxifying your packages and stuff like that is important. Do you think there is still unsolved problems? What are the hardest problems for now to even get to what you just mentioned as the future hot take?

Is there a couple of things clear, but some things are not so clear? I think on the Fox roadmap, it's clear, but I think it's clear what we need to do. But I think the complexity of how we need to do that is what we're trying to unlock. So what's happening right now is with Fox, you have this thing that can... It's a new approach to building and packaging software that can, you know, is unified across all the stacks, can be reliably audited and works across all platforms. But bottom line, what does that do? It's like, you can get an environment set up and running instantly. It can be shared. It can be, you know, Ian can be running a Mac. I'll be on an Ubuntu. Tim's running some other wacky Linux version. And we'll all be able to work on the same thing, right? I can make open source projects much more accessible. It's like,

there's all of these beautiful things that we can do. The really complicated piece for us next is like, how do I get you through into a build? Because that's what I really want to do. I want you to be able to take your project and build it with Phlox based on all of this magic that we just talked about behind Nix. And I want you to have zero complexity. So the thing about Phlox today is that you don't need to know Nix at all in order to use it. It's a product.

It's a developer tool. It's free. It's open source. Just go into it and just use it like you would use anything else that's right now common in the ecosystem. The build for us is what we're really trying to crack because that's where it gets really complex. How do I take your software, mix it back into Nix without you having to go and

redefine the world, which is what you would have to do if you would do native Nix today. And I think that will be the biggest unlock for Phlox and Nix to bring a huge part of the software ecosystem just right over the fence to now we have Nix builds. Because once you have a Nix build, pretty much everything else comes for free. That's kind of like the area that we're exploring. And by the way, if anyone's listening and in the build space, we'd love feedback.

We're just exploring that very actively in terms of like, what do you care about? What do we need to make easier? And things like that. So I think that's a really good question about where is it really complex. I'd love to, like, from your perspective in five years, how much of the ecosystem do you think Nix has eaten?

How much of the package, like, get me my dependencies so I can do something? Like, you're going to eat all of Apt, we're going to get all of, you know, Brew, you're going to get all of NPM. Like, how far up the stack of, like, like i gotta get some stuff in an environment so i can do some stuff does nix and floxy like i'd love to get your take on that we have users that don't use anything but flox even to install software on their machines and that's flox and we know for a fact that thousands of folks on nix os which is one of the like you can use nix os if you want to get really good access into nix but but then you're switching operating systems. Don't use anything else. For them, it's a

replacement for the app, the brew for pretty much managing everything they need on their machines completely. So again, like, maybe it's part of the hot takes. Like, I think that you don't need anything else. But that's like a very biased, scary thing that no one says so. Awesome. Well, for people that never even used Nix, which I'm sure there's still quite a few out there, and Phlox, where should they go? Where should they go to learn and maybe even try and use Nix and Phlox? So obviously Phlox is catered to folks that have no clue about Nix or want to, you know, have clue about Nix, but don't want to kind of get into the intricacies of it. And that's just Phlox.dev. Five minute quick starts, team's always around to also like we

have a community channel. We love helping like new projects set up their Phlox environments, and then you can just get started. If you want to dive into Nix, there's an insane amount of resources. So nixos.org is the main site. And then there's a documentation website that you can link from there. There's a bunch of YouTube content that we've put out. We just organized NixCon for the first time in the US a few months back. And Tom, our head of labs and Rock, one of our engineers, did an intro to Nix YouTube, like a video session, which I thought was super helpful. In general, if anybody just has curiosities about Nick's and just doesn't know where to start, like Matrix Channel, ping me on any platform and Ron at flocks.dev and I'm happy to help out.

Amazing. Ron, it's been such a pleasure having you. And I'm so excited for the future of never having to try to debug a local development environment ever again. So this is incredible. Thank you so much. Awesome. Really appreciate it, you guys. This was awesome. And thank you.