Ep. #12, Exploring Flox and Nix with Ron Efroni & Ross Turk

Brian Douglas: Welcome to another installment of Open Source Ready. Always, John McBride joining me. How you doing?

John McBride: Hey, I'm doing good, Brian, how are you?

Brian: I'm doing great. I was actually thinking, your last name's Scottish. My last name's Scottish.

John: Irish. Irish.

Brian: Oh, is it Irish? Oh, McBride. Oh, okay.

John: Yeah, of course. And my middle name is Patrick, so John Patrick McBride here. I got to make it back to Ireland someday, but we'll see.

Brian: The joke I was going to make is that we're both Scottish co-hosts, but anyway. Listeners, you'll have to watch the video after the fact I'm not Scottish.

All right. So we actually have guests here. We're not here to talk about our origins and our heritage.

We've got two members from the Flox team actually. So we got Ron. Ron, you want to say hello?

Ron Efroni: Hey, super excited to be here.

Brian: Excellent. And then Ross, who I've not met before, so Ross, pleasure.

Ross Turk: Yeah, glad to be here. Good to meet you.

Brian: Cool. Yeah. So Ron, what are you guys working on?

Ron: We're working on Flox. I can give a brief, quick background like, just to introduce.

I'm Ron. Before this, I was running Facebook's developer product space for them here in in California. And pretty much the journey took me into Nix land.

I started this project called Developer on Demand with a bunch of people trying to replicate the iOS tool chain on Linux, which I think might touch John's areas.

And pretty much kind of recognize how beastly levels of complexity there is in trying to replicate a tool chain when you're just trying to build stuff.

We were able to be successful, replicate it on Linux, put up VS Code as a front end. A bunch of developers threatened to quit because they were moving off Xcode.

That's a conversation for a later time. But then, you know, build speeds for our monorepo went down from like 40, 45 minutes to 30 seconds.

Security aspects came up. Like, there was a lot, but that's what brought me into Nix, which I'm sure we're going to have a chance to talk about.

And then also that's what got me to meet my co-founder at CTO, Michael, who was the head of build and release engineering for about 20 years at a firm called D.E. Shaw, where he, back in 2017, 2018 brought Nix for the first time in an enterprise and built kind of Flox v0.1.

And then him and I pretty much launched it as a startup in late '21, early '22. And today I'm also the president of the NixOS foundation. And we do a bunch of things on the community side.

Brian: And Ross, what's your role at Flox?

Ross: So that depends on who's asking. If you're a professional, I'm VP of marketing and if you are not, I'm Head of Words and Pictures.

I've found that using Head of Words and Pictures actually is a much more vibrant title 'cause it's what I spend my whole day doing, is figuring out how to explain what we're trying to do at Flox and how to show people what makes it different.

And a lot of that is words and pictures.

Brian: Yeah. Yeah. So I'd love to like take a step back and you mentioned Nix Os as well, Ron, so I appreciate that.

'Cause I didn't know what Nix was prior to like, maybe four years ago. I don't even know its origin, to be quite honest.

I just know that people got really excited about it. Like, developers got very happy about the idea of Nix. And then I had once looked at the Nix repo and it was like, massive.

And actually for open source, we were trying to index some large projects that Nix was throwing out there.

And I was like, no thanks. Like, that's too much information. Let's find something smaller with less activity.

So any of you want to want to take over, what's Nix? What is this thing?

Ron: Yeah, I mean Nix is a lot of things. So let's start off with that.

I think Nix today is everything from the world's largest package repository to its own language, to an operating system, if you want to just rip it all out and slam Nix into it.

The first time I went on stage right after Covid, we were organizing NixCon, it was in Paris and there was a huge image.

I know this is voice. So imagine there was a huge image that I put on stage of the infra map, you know, the CI/CD, the developer environments, just everything over there.

And there was a whole like, 22nd slot where the entire room together with me was like, yup, Nix does that and Nix does this and Nix does that.

It's a lot of things, but I think the beauty of it is that there's a few core principles that Nix really shines. And that's also the kind of the things that Flox brings into the world.

I would say the crown jewel of Nix is actually Nix packages. That's where there's, you know, it's the sixth largest project on Git up to date, 10,000 plus active monthly contributors. And that's where a lot of the core principles that we're bringing up into the industry kind of come out of and are made possible.

A little bit about the history there, Nix was started by Eelco as a part of his PhD thesis 20 something years ago.

And the high, high level of it, it said kind of the way I viewed it, it comes and says, why does everything have to be different in software? Right?

Which is kind of weird, 'cause 20 years ago was much simpler than it is today. So there was a lot less complexity, less languages, less repository, less reliance on open source, there's so less.

But even back then, it came and said, what if we can have one type of architecture that everything lives through, right?

So your packages are a package, your dependencies and your libraries are packages.

But wait a second, what if we made your builds a package and your environments a package and your dev setups a package and your deployments a package?

But everything was this tree that is interlinked to each other, which sounds hideously complex.

And 20 years ago, I would say you're pretty insane to think that this would be achievable.

But, you know, 23 years, tens of thousands of contributions and contributors across that time kind of made it possible. But I'd also love to hear Ross.

Ross: I think it's a really interesting project. I've been looking at open source like, my whole career. It's what I focus on.

And this project blows my mind because it's been around for 20 years and it's really gigantic, but it's super decentralized.

There's no BFDL, there's not even a DL, there's not even an L. It's really decentralized and decisions get made in a decentralized way.

And so what you end up with is this kind of ecosystem around Nix where a lot of stuff's been built and you can find all kinds of different usage patterns to find in the Nix ecosystem.

And it's sometimes hard for people to know where to start. And I think that's where Flox came in.

We have this really interesting situation in that we were born from a user, D.E. Shaw, that was trying to deploy Nix and just found stuff missing.

And what was missing from Nix was basic package manager semantics that everybody can understand.

And so the co-founder, Michael Brantley, invented Flox initially as a wrapper around Nix just to kind of be a convenience thing so people didn't have to remember all the different commands.

But then it really quickly grew to a thing where it was more than that.

It was a new paradigm on top of Nix that sort of took the principles of Nix and all of the goodness that's in all those packages and made it really easy for people to use who maybe didn't have the time to learn a new tool or a new programming language or a new thing like that.

And they were also able at D.E. Shaw to centralize what happens in Nix so that they can have some sort of centralized management over their software supply chain.

So I think what's really interesting is watching this Nix community generate all this potential and all this possibility and then seeing what happens when a really serious financial firm tries to absorb all of it and decides what's missing, figures out what's missing, and then spins out Flox as a company. It's like the best kind of thing. It was invented by a user.

So that's what made me really interested in looking at Flox. But Nix as a community is, I've never seen anything quite like it.

John: Yeah, I've been using Nix for a good little while now. On and off I was on Nix desktop for a little while, which was a fun experience. But you know, that's maybe for another discussion.

And I spent some time at Amazon working on Amazon Linux and Bottlerocket, which for those who are unaware of Bottlerocket is kind of this insane, highly secure, you know, for your Kubernetes nodes, Linux distribution, but both Bottlerocket and really everything within Amazon Linux is Fedora-based.

And, you know, you don't have to answer these questions if you don't want to, but I had this crazy conversation kind of in a team meeting one time where somebody, they'll go unnamed, was basically trying to propose using Nix instead of RPM, which is Fedora's whole, you know, awful package managing solution to basically rebuild Bottlerocket.

And one of the principal engineers said that as long as he was at Amazon, Nix would never be at Amazon.

Which just blew me away, 'cause I was like, is this like, the old guard saying that we're not going to adopt this new technology or this new stuff?

You know, and like, candidly Nix does have this kind of reputation of being, divisive, maybe is the word.

I'm curious what your comment would be there. Like, why does Nix have this reputation?

Ron: I think there's a lot to unpack there. I think there's a lot of open source projects out there.

There's a lot of projects bigger than Nix, smaller than Nix, more complex than, oh, more complex could be, you know, to the viewer's discretion.

John: Right, right.

Ron: But I think one of the things, 'cause I've been thinking about that a long time, like what made Nix and the community and us so unique?

I think there's a situation here where you have a technology that kind of, and I know I'm going to come off very biased, right?

But it's kind of like, it was kind of clairvoyant. It kind of came 23 years ago and said, "All right, here's this concept. None of you need this yet, but I'll be damned in 20 years if more and more people don't recognize that they need this yet."

I think 20 years ago, right, it created this scenario where unlike other open source projects, like Linux-based projects, you know, like all of these amazing things, it didn't immediately solve a pain at the ratio of, you know, cost to benefit.

But it was so intrinsic in changing a software principle that it slowly did acquire an ecosystem and a community around it.

So the way I like to think about it is think about those first 15 years where you use Nix because you either really understood it or you saw or understood the future, right?

You were able to kind of foretell what's going to happen in five to 10 years or you're really passionate about it.

And I think what happened was that there was this unique situation where for about 15 plus years, the Nix community slowly was comprised of a lot of folks that really believed in this as where software is going rather than necessarily pinpointing a market problem and solving it with a container.

Right, and I think that created a very unique situation that we are now seeing just like, bubble up and bubble up, where in Nix there's a lot of, like, some people laugh at this, some people don't laugh at this. It feels kind of like a religion. There's this concept of purity in Nix. Yeah, I'm sure John, you know this.

John: I can't help but laugh. Yeah, it's so true.

Ron: Yeah. There's a lot of these concepts that I think didn't have time to grow in other ecosystems, 'cause very quickly they became in the market and adopted by companies.

Here you have like 15, 20 years of some of the smartest engineers just working very passionately on this project.

So purity, for those that are listening in, in the Nix realm, it talks more about like how your package becomes a package and it has to follow all of these very strict guidelines in order for that package to come out pure.

Now, why do we care about this? And again, when I say purity, it feels so much like a religion. But we care about this because Nix gives you all these promises, right?

It gives you this promise of reproducibility. 20 years ago, no one really cared about that. Now it's starting to become a thing, right?

We want our software to be reproducible. It gives you this promise of security, right?

We at Flox call it security by construction because inherently, Nix forces you, purity, to have everything that you build, everything that you package, everything that you do, including your builds itself and your artifacts, have a full log of the runtime and build time recursively all the way down to libc.

Right, 20 years ago you'd be like, "That's insane. We don't need that. Why would we need that?"

But today with, you know, software supply chain and attack vectors and all of these new concepts coming up and like, complexity and being able to be portable and agents and all of that, suddenly you're like, yeah, I kind of want that.

But to your point, John, about this old guard saying, "I will never use Nix." I think for a very long time it was kind of like a, you have to do it our way or the highway.

And that's why I really resonate with folks that you know, I don't blame them because of, it kind of did feel like that for a long time.

Ross: I think the core fundamental technology of Nix is kind of controversial. Like, if you've been using UNIX for 30, 40, 50, a hundred, a bazillion years, right? It's timeless.

If you've been using UNIX this long, you expect your package manager to install its stuff into user bin and user lib and you know, at C and all the places that UNIX software gets installed and Nix doesn't install its software there, it installs its software into a Nix store and then you create profiles that weave together that software into all these different contexts.

So adopting Nix isn't just about the build process. The users have to adopt it too. And so I think that's one of the reasons why it's such a big lift is you don't just reach inside of UNIX and change something fundamental like where software lives. Everything above it has to be refactored.

And if you look at how Nix accomplishes this, it's with wrapper scripts and pathing and symlinks and all of this stuff that happens on top of this fundamental decision that Nix makes about where software lives.

I think that's why it's been a 20 year project and I think it's been a project waiting for a world that really cares about being persnickety about its software supply chain.

So I think the business world has caught up with being persnickety about this in the way that the Nix folks were persnickety about this for 20 years.

John: Yeah, those established expectations within the OS layer are huge.

Like, to play devil's advocate to, you know, I understand why Amazon Linux 2 can probably never get off of Fedora, because there's probably a thousand and one businesses that rely on DNF being on, you know, their one EC2 instance sitting around, which is the fedora package manager.

Or you know, just this one thing sitting, you know, within the exact path that fedora provisions it, one way or another.

How do you start to like, break down those barriers? Like, I think one thing for me that was revolutionary, just really blew my mind.

One of my former colleagues, Josh Rosso, who is a principal engineer at Reddit, he gave this like, incredible talk at KubeCon last year sometime about building Kubernetes distribution node images with Nix.

It was kind of insane because it was like just a few, you know, just the configurations, the reproducible builds and that was like a lot of what, you know, some of the teams on EKS and the node teams trying to, you know, bootstrap things within the Amazon Kubernetes ecosystem were trying to achieve.

And then here's Josh doing it like, willy-nilly in his talk and like, we're just using Nix, it's great and you know, put Kubeadm on the thing and it just works.

So how do you start to break down those barriers like, for the existing old guard and how do you start to like, you know, change people's minds I guess?

Ross: Well, I think the first thing is you want to provide them with workflows that they're a little bit familiar with.

That's one of the things that Flox does on top of Nix is it provides this ability to do like init, to initialize a project and to install a thing and uninstall to uninstall a thing.

And it has a manifest, its TOML. And I think that a lot of it is, there's going to be a phase where we're doing some impedance matching, where we're building these things that take what Nix does and represent it to people who have existing stacks and can't just rip and replace the whole thing.

I kind of think the Nix dilemma is, I call it the comfortable chair dilemma, where Nix is an amazing chair, you know, it's got your remote control built into it and a cup holder and a massager and it's this amazing chair and everybody's like, yeah, but I'm already sitting down, you know, like, I'm already doing it the hard way.

I already put a pillow, shoved it underneath my back and I got my arm propped up on a thing and I taped my remote to the side and people are already sitting down.

And so I think part of it is you've got to figure out how to meet people where they are, find a problem that they're experiencing today.

Not the biggest, mountainous problem of your software supply chain, but maybe a problem like, I want to be able to create an environment that materializes to native binaries on Mac and on Linux, but yet has one manifest.

That's a problem that we can solve today, really easily. It's a problem Nix is really, really great at.

So figuring how you can take a bite at this problem instead of trying to swallow the entire thing.

Ron: Yeah, and I think for me there's three. There's like, three things that both with my like, NixOS foundation hat and with my Flox hat I continuously try to achieve.

I think one is that for the longest of times, Nix has been everything for a lot of people, but it can't be everything for everyone.

And I think that's with my Nix foundation hat on, right? If we want Nix to proliferate in the world and to be adopted, I think it's like, we have to accept the fact that there are going to be folks who are going to be using containers on the right and they're going to be using another package manager on the left.

And we need to be able to, to Ross's point, meet developers where they're at.

And that's one of the core principles like, leading a lot of the product management prioritization inside of Flox, right?

It's like, really understanding our developer ecosystems, what they're using, what they love to use.

And I think this is also coming out of some of that time at Facebook doing dev products, it's like we really just want to come in and solve a problem for you, not tell you to replace your OS, not tell you to throw your CI/CD system in the trash or stop using containers, right?

We just want to tell you, I think to that talk that you mentioned from Reddit, we just want to tell you, hey, you can do things better.

You can have like, a nicer life tomorrow morning and let me show you how to do that. That's one. And that's like, the whole simplicity, meeting developers where they're at. I think the other is that at its core, Michael and the team have been really able to understand the gaps between what Nix requires and what an enterprise needs.

And I think one of the best examples for that is going back to that purity clause. Nix forces you to be able to understand all the dependencies for what you're bringing into its ecosystem in order for it to be compatible.

What that means is that technically your source code is somewhat available, right? Because if I don't know the recursive dependency tree, then how can I approve you inside of Nix packages?

Now when you're a part of an open source community, that's great, that works.

But when you start coming into enterprise, they don't love sharing anything that might give a sense of what they're building, what they're doing or anything proprietary.

So Michael and the team have been working for a really long time on something called the Flox catalog.

Right, so I went from like, talking about like, the general concept of just something that's a bit more technically based.

The Flox catalog sits between the user and Nix packages. But the Flox catalog allows the users, the customers, the engineering organization, the engineers to actually build their own things privately, keep them private, and then still be connected to Nix packages, Nix itself and receive all those benefits.

So there's kind of like a pull on both sides, right, that we're mentioning and also just very critical infrastructure tech that is required to kind of meet those folks inside of their workplaces.

So I think those are some of it. And it's also definitely about how we start focusing and talking about what Nix really, really shines bright on.

Right, so going back to my point about Nix being everything for everyone is kind of like setting us up for failure.

Being able to say, and again, our opinionation in Flox is like, three out of the 50 things are the really critical one.

It's the whole concept of universal environments. Like, you can take your stuff anywhere.

You don't need to care about the OS, the metal, the architecture. Like, you can certainly having this universal platform, that's one, the whole build area is another.

And obviously security is a third.

Brian: Yeah, it's interesting, 'cause I feel like there's a lot of things happening right now in the industry of like, okay, there's like new guards coming in, there's old guards that are like, relicensing and getting acquired by IBM. So now we're like-

Ron: Not calling out anyone specifically, but like-

John: Yeah.

Brian: Yeah, I was just trying to be hand wavy about that. But there's this one question that I linked it here in the show notes about Docker and like, is Docker dying?

And like Ross, you had mentioned like, or you kind of painted the picture, Ron, about like, okay, you want to meet developers, actually Ross said, meet developers where you are and you were talking about sort of like working with containers.

Like, Docker's gone through some ups and downs, even in the last like, two to three years, which has been absolutely amazing to like, watch as they seem to have had their footing.

But I guess the question I have is like, well the question on Reddit, it was like, is Docker dying? But-

John: Well, and speaking of Docker, I don't know if you saw the news today, but they're changing the poll limit for unauthenticated accounts to only 10 polls per hour, which is quite dramatic.

Brian: Wow. I did not see that.

John: Breaking news. You heard it here first.

Brian: All right. That's what Open Source Ready is for. Breaking news of the nines. Just kidding.

John: Sorry to interrupt you Brian, but yeah, I think that's an excellent question to go into.

Like, where is the state of like, containers and like, these companies that surround containers and now even like, the open source things that could maybe replace those.

Like, where do you see Nix and Flox stepping into there?

Ross: It's been interesting to me to watch what containers have done to this ecosystem because I see it as an infrastructure technology and I think like, okay, I reach for this technology when I need to isolate some infrastructure or I need to, like, I think about it as an infrastructure technology, but I think the world has adopted it largely as like, a packaging mechanism.

So I look at Nix and containers as not being competitive because I think of one as a build and packaging system and one fundamentally as like, a infrastructure thing. But if you look at how people are actually using them, I think you can use Nix to get the same level of isolation around software or at least to assemble discrete collections of software. So Nix is really good at assembling discrete collections of software. Whether you need that inside of a container or not, depends on your use case.

So I don't necessarily see them as being in conflict with one another. I will say I really do enjoy using Flox in Nix locally instead of running things in containers, getting access to that bare metal, not shaving half of my ram off for some VM somewhere.

So there's a flattening the stack thing that I really like about it, but I don't think that they conflict. In fact, we're about to publish a blog post that lists a bunch of different methods for taking Nix profiles and putting them in containers and talking about why you might want to do that.

Containers are great for shipping in, ironically. So I think my personal opinion is that we've overloaded the container. We've taken this incredibly useful thing that to me, I've always seen as like, a VM but tighter and we've turned it into something a lot more than I think it was ever intended to be.

So I would like to, I don't think Nix competes with containers. I think Nix competes with Dockerfile. That's what I think Nix competes with.

Ron: Yeah, and I very much resonate with Ross. I think there's like, two sides of this for me.

It's like, one with Nix and with Flox it's just that developers have more options to that point, right?

Like, you're not forced to kind of, and I for some reason run on food analogies and I know at some point you want the Nix for a five-year-old.

I have one like, lined up perfectly for it. Let me know.

Brian: Oh yeah, let's hear it.

Ron: So my food analogy on this one is like, you know all those food services that give you, you know, all the ingredients in a box to make a meal?

That's how I sometimes think about how we ship things to our developers.

It's like, do we want our developers to be the chef in a Michelin-styled open kitchen with every ingredient on earth super fresh and you just tell them, "Hey, make magic happen" and they make magic happen.

Or are you shipping them a box with like, you know, four carrots, two pieces of celery, like, half a chunk of tofu and you're telling them go make me some miso soup or something. Probably messed that up. There's no carrots in miso.

I think on one side, it's like, there's now a paradigm shift with a principal shift where developers are, you know, going to have more optionality.

Whether it's Nix, NixOS and Flox are going to be able to do things differently if they want to.

But to Ross's point, like, the core concept here is meeting the developer and the folks where they're at.

So Flox, one of our core functionalities, Flox containerized, where you're able to actually create a container out of Flox and out of Nix.

And guess what? That container is the most optimized one you can probably pull out of anywhere because it's going to only have the things it needs and it's going to be slim, it's going to be fast, and it's going to be able to build pretty quickly.

And we even have a talk about it at the last DockerCon where our head of labs and Docker head of labs talk about Nix and Flox instead of Dockerfiles together.

So I think that's kind of how we view it today.

John: Yeah, I think it's funny to have like, worked in like, a core container technology in the past with like, run C and container D and seeing like, those underlying technologies like, kind of be able to breathe is really interesting.

Like, you can have a C group that just isolates CPU resources while giving full disc and you know, full ram and all those other things.

But like, you sort of, with Docker you just get, and I guess really, Podman or nerdctl or any of these, it's basically like, no, it's going to be the whole thing.

Like, you don't get access to, you know, the whole kitchen. You're going to ship a container and it's going to have its own namespace, its own C groups within, you know, like, all this stuff and you're not going to get disk check.

You can set those options within a container on Docker and stuff, but it feels like the default has sort of just become like, yeah, you're just getting this box and we're shipping that whole thing to you.

I really like that food analogy 'cause there's a lot of options actually. And sometimes I just wish like, the Linux container paradigm was a little more accessible.

Maybe accessible is not the right word. I don't know what it is, like, approachable.

'Cause it is pretty gnarly and I don't know if I'd want to be going, you know, setting manual C groups or namespaces myself all the time, right?

Ross: Yeah. So we ship software to developers. The metaphor being like, if it's, we're shipping them a container of fried rice and they have to crawl inside the container to eat it. Ha ha.

John: Hilarious.

Brian: Yeah. Oh man, that's a crazy visual. I was thinking like, Ron, I wanted to hear your, "explain to me like I'm five" for Flox.

Ron: Yeah, so my explain it like a five- I actually did this in the last NixCon in the state of the union that I gave.

So, you know, I'm a very mixed heritage background. Like, I have grandmas from Africa and a grandmother from like, Poland.

And the thing I pulled was like, do you have that recipe? Right, do you have that recipe that your family's been trying to recreate, you, your mother, your grandmother?

I don't know who it is, but it's ink on paper, right? It tells you to kind of bring in the example here was a veg goulash for those interested and those interested in goulash, it was a veg goulash.

But it was, you know, it lists like, zucchini, and it has like, paprika, and it has, but it has this list of ink on paper, things that you need to follow in order to recreate this dish that you're really looking forward to.

And I feel like in the non-Nix ecosystem, that's what we're dealing with. We're dealing with this like, ink on paper, you know, bits on a screen of how to recreate something and then we do our best to recreate it, right?

We pull Python and it's like, it's the Python that grew in my backyard, not in my grandmother's backyard, right?

But imagine that I could give you something that magically gives you every single ingredient that your grandmother used to create that veggie goulash and then was able to replicate every step, right, with the ambient temperature in the room and the soil that the tomatoes grew in. And everything is recreated to that level of granularity. So when you take that first bite, you cry, you smile, you go through like, a whole life of emotion.

Like, you know, John's laughing because like, this is where the Nix religion of me is coming out.

John: Yeah.

Ron: But that's like, my five-year-old thing. It's like, imagine you had this magical cookbook that every time you open that page, all the ingredients appeared as if it was your grandmother pulling them out of the garden.

Brian: That's pretty good.

John: I'm crying right now. Amazing.

Brian: I had my own very own "Ratatouille" moment thinking about my grandma's dish.

John: I have another slightly spicy question. One of my favorite uses for Nix is as you know, the Nix shell on macOS.

So I can like, have all those packages there just on Mac and it just works. I can kind of get rid of Brew, you know, shout out to the Brew people.

They did amazing work, I think, in an early ecosystem for, you know, where Apple sort of dropped the ball in my opinion.

But why doesn't macOS have a package manager? What were they thinking?

Ross: Well, I'll go a step further. When I set up my Macs, I don't even accept the Xcode license anymore, right? So there may be an answer to your question there.

Apple already distributes Git and they already distribute all the things that they think you need. It's just part of their Xcode package and you have to agree to their license agreement.

So I don't do that anymore. I just use Nix and Flox to get all of my stuff and as a result, I'm not using Git that's 10 years old. So there are some benefits.

Ron: I would say like, you're right on the money there.

I think, you know, internally, one of our biggest like, bottoms up adoption motions that we've been seeing throughout 2024 have been people literally replacing Homebrew with Flox.

It's free, it's open source, it's based on Nix packages.

Like, I think one of the biggest waves that happened was when Kelsey Hightower started talking about replacing Homebrew with Flox and I think that brought like, a huge wave of Flox. But to Ross's point, it just gives you everything you need and all the principles and the benefits of Nix just for your home environments. And we've all been using it for a long, long time.

John: Yeah.

Ron: And I think to your question like, why Apple hasn't done something there. I mean, I love Apple.

I did have some friction when they, initially I was running like, all our IDEs inside of Facebook as well and then they were like, yup, no plugins on Xcode. Good luck.

John: Whoa.

Ron: I think there's a lot of focus around like, the app store and like, system-level frameworks, not necessarily the CLI parts of things that leaves that gap.

I can only assume that there's like, a strategic, that there, I don't know if it's a monetizable one.

'Cause when I look at our users and folks and ourselves using Flox instead of Homebrew, that's like a free for life thing, right?

So I don't know, maybe it's kind of like, on that side for them. But definitely a good question.

John: Yeah, macOS is funny to me. I mean, for some reason recently I've been going deep on Automator, which is like, you know, nothing you ever actually want to say in your life, but here we are.

it's a pretty cool suite of you know, macOS automation tooling, you know, you can have apps that cull other apps or scripts that pipe things into, you know, the mail app or whatever.

So I can, you know, have various things happening.

But it does feel like one of those things that I'm kind of ready for the rug pull, where like, you know, macOS 21 is just going to get rid of Automator.

Because it's a clearly older, maybe rotting away piece of tooling that feels like a bygone era of like, developer focused, you know, Apple tooling I guess.

Ross: Yeah. And investing a lot into Automator workflows is really just tying to that one platform as well.

I use Automator for things that are really native to Mac, like Final Cut workflows and things like that.

John: Exactly. Yeah.

Ross: But for everything that I might want to lift and shift to Linux, I actually go to some extent to make those things portable.

I'm always jumping around between operating systems these days. I don't know if you are, but I can't stick with just one these days.

Brian: Yeah, I enjoy the flexibility and I'm sitting next to a PC that's got a GPU in it.

So like, I've only just now started the right code on a PC and on Windows. So I enjoy the flexibility.

Though that's quite a callback. I've not even thought about Automator since like college, maybe, is like, the last time I touched that thing. Yeah. Who who've thought.

I did want to transition us to the reads. So my question to you, Ron and Ross, are you ready to read?

Ron: Hell yeah.

Brian: Cool. So I've got a couple of reads and I appreciate you all, you know, talking through the, "Is Docker Dying?"

I have been doing a lot of reading and catching up, mainly 'cause John's been like, building this cool little framework in Go.

So I've been like, kind of tinkering around with like, some of these like, new AI startups and projects and got kind of dug into this like, MCP protocol that came out of Anthropic, which is the sort of protocol framework to build agent-ready applications.

So my read is basically they have a blog post which is pretty underwhelming. It's just got a bunch of links.

The one link is actually the GitHub repo, which I was surprised to see some stuff in there.

And then yesterday I had coffee with a founder out of Berlin who's doing memory caching for LLM, like long context windows and he had mentioned he's adhering to the Anthropic MCP protocol as well.

So it seems like this thing, it was announced late last year, like October, November, it seems like it's getting some legs and you know, what developer doesn't like a new protocol, a new framework to take a look at.

But literally today, we also saw Ruby on Rails announced, Active Agent as well, which is like my other sort of sneaky second read.

I haven't used Ruby on Rails in like, probably since 2018 was the last time I built anything in it.

But framework keeps moving forward and I truly think we're seeing a second wave AI engineer coming in the fold where like, folks who kind of had their feet dragging on AI haven't really paid attention, just doing their job day to day.

There's a bit of an open berth of more and more people being able to ship AI tooling and AI projects as well.

So with Ruby on Rails, with the MCP protocol and all these new tools, there it is. But yeah, happy to hear thoughts.

Ron: From my end, I think, I'm loving this, 'cause I think we've been, so the overarching thing that I'm seeing is that just like every new technology, like, AI has been on a boom, right?

How do you catch up when things are moving faster than you, right?

Startups have a lot of risk, but the thing about startups is that you have this team that is really in tune with the market today, building a new technology based on the latest.

How do you do startups when if you have a team that's older than three month old, they're already not in tune with the latest, right?

So I'm kind of excited about the fact that we're starting to look towards that standardization front for AI. 'Cause that, generally, I think that's where most of the innovation is going to come from.

Like, all of this model thing and things moving every week and DeepSeek coming out last week and things coming out next week.

Like, that's exciting, but that's not what ends up building things that make me have a happier life.

And the things that make me have a happier life happen once we have a moment to actually sit down, look at the state of the world and figure out what we can make with this that makes people's lives better.

Right, so like this MCP protocol about standardizing kind of like the context and the the models, I think that's like, another step forward because if we have more standardization on how things are consumed, I think the two main benefits that I care about is one is like, we can just have more consistency and more security coming in from the model landscape.

And that's again going to help companies, innovators, founders, startups, be able to put out products out there that are more reliable.

The second thing that I'm excited about is like, we're four people on a call.

We have totally different models running in our head right now, interacting and we're, hopefully, generating good benefit for others as we're riffing here.

But I do believe that humans in general and like, the four of us, we have some form of standard baseline, right?

We're not like four different fully, like, unrecognizable entities clashing all at once.

At the end of the day we're humans, we have somewhat similar backgrounds, we have some form of baseline.

So I think this whole concept of protocols that help like, models have an interop layer.

Like, imagine that one model can start understanding and communicating better with another model and they can start building up on top of each other, which I think is what we do as humans a lot, is something that I'm more excited about about the the next friend for AI.

John: Yeah, a hundred percent. It's one of those things that I'm like, kind of shocked that Anthropic did because it actually moves a lot of like what's being built in the model and API layer of out of it into a protocol.

Example is tool calling, I think is the obvious one, where like, OpenAI and you know, some of these early foundation model companies sort of pioneered the techniques of tool calling, which was really just like, fine tuning a model to respond with JSON based on a JSON schema that you gave it.

And like, moving that into a protocol layer where it's not just reliant on, you know, some models spitting out the right JSON to you is honestly brave because now it's, you know, sort of enabling your competition a bit, but also that standardization, I think, is just going to be huge for building on top of these things in the future.

Ross: I think there's going to be a really interesting collection of products in the ecosystem around governance for agentic coders and agentic infra deployers and all of that.

It's going to be really interesting. Another thought I have on these reads, just kind of jumping around is, I'm curious how AI's going to do with Ruby and Rails.

I found that AI code generation is inconsistent. My colleague Michael, our head of engineering, finds that his favorite is Go. I'm finding some luck in Python.

But I would tend to think that Ruby and particularly Ruby on Rails might actually be a really good candidate for agentic engineering, just 'cause it's so convention-focused and so idiomatic and so like, I wonder like, how do we actually start choosing the right languages for agents to code?

Pearl is not the right one, you know, so we can start there.

Brian: Yeah. Cool. John, do you have some picks for us?

John: Yeah, I'll mention one read this week, which was this awesome piece called "A year of UV: pros, cons, and should you migrate? Yes, probably."

For those unaware, UV is, you know, and I thought it was very relevant for this conversation.

UV is a Python package manager kind of environment, bootstrapper kind of uber tool for the Python ecosystem.

It's built by the people at Astral.sh, I'm a huge fan. It's built in Rust. It has some of the fastest package resolution you can do in the Python ecosystem compared to like, Poetry and PIP.

And recently at the Linux Foundation, within our internal engineering org, I've been sort of evangelizing it and I just think it's amazing. It's great.

Really, it took UV for me to be like, a Python believer because like, before that, with like, Honda and like, pyenv and HIP and all this stuff, it was just so nasty and gross, so huge shout out to the Astral.sh people.

Yeah. Ron, Ross, curious if you've tried this tool before?

Ross: I have been hearing about it nonstop and honestly I haven't, because I'm in my comfortable PIP chair.

John: There you go.

Ross: And I just haven't found that moment in my projects where I want to stand up from it and move over to another one.

I'm using Flox to sort of orchestrate 'em all and I've been tempted to switch out PIP for UV underneath and see what it would offer me in my context.

But I've been hearing everybody talk about it.

John: Yeah. I'd honestly be very curious to see a setup. 'Cause you know, UV is very flexible in this way.

You can use PIP with UV, but I'd be very curious to see a way that you could like, set a Python environment with Flox or Nix and then, you know, use UV to actually resolve the packages.

'Cause you know, UV can get you Python if you need it in a virtual environment or something. But you know, Ron, is it possible, could we do this?

Ron: I think one a hundred percent. I think that's one of the concepts that we're looking at with Flox and Nix, 'cause it lets you bring in and integrate all of these tools.

And this goes back, I think to the whole concept of what we said at the beginning of the episode around meeting developers where they're at.

Like, you want to use UV, you want to use PIP. Like, you can use that and we'll just start standardizing it so we can roll things forward.

Ross: What we probably could do, so when you initialize a new Flox environment and you're in a directory that already has requirements for that text, it creates you a manifest that does the Python wrapping for you.

We're not currently looking for UV files or artifacts. So that would be something we could do to make it so that if you have a project with UV that it could initialize automatically.

There's plenty of work we could do around that. I think that Flox being kind of a package manager to rule them all is a really good way to think about it.

You know, the, I call it the everything bagel with package managers, but that sort of suggests that you don't need any others. It's more like one that orchestrates the rest.

Ron: We haven't had lunch yet, that's why it's all the food references coming in.

John: You're you're making me hungry. I'm ready to go eat now too.

Ross: We've been using all these food metaphors.

John: Ron, did you have any pics or does this links for us to check out later?

Ron: No, these are just links on the topics that we talked about. They're actually, Ross did do something with DeepSeek and Flox.

There's like, a whole local model thing that you can do with Flox that's pretty amazing and we can share the links to that.

John: Nice.

Ross: Yeah, I'll share the link to that. There's a example environment on Flox Hub that will set up Ollama and an Ollama UI for you and let you get up and running.

And we wrote a blog post. A lot of the heavy lifting there is done by Ollama. Ollama's amazing.

Flox is a great way to install it and it helps you orchestrate and set it up and all of that.

But huge fans to Ollama, like, big love to the Ollama team.

Brian: All right, well with that, I appreciate you all coming and chatting about open source and talking about Flox and catching me up on Nix and all these food analogies.

With that, listeners, stay ready.