Homebrew and macOS Package Management with Mike McQuaid

0:00Homebrew is a widely used package manager that simplifies the installation of open source software on macOS. It was created in response to the growing demand for a lightweight, developer-friendly tool suited to an increasingly Mac-centric development ecosystem. Today, Homebrew is a near-essential part of the macOS software development toolkit. Mike McQuaid joined the project early on and collaborated closely with its creator, Max Howell. He joins the podcast with Kevin Ball to discuss Homebrew's origins, architecture, its emphasis on automation and CICD, long-term sustainability, controversial trade-offs, and much more.

0:41Kevin Ball, or Kate Ball, is the Vice President of Engineering at Mento and an independent coach for engineers and engineering leaders. He co-founded and served as CTO for two companies, founded the San Diego JavaScript Meetup, and organizes the AI in Action discussion group through Latent Space. Check out the show notes to follow KBall on Twitter or LinkedIn or visit his website, kball.llc.

1:16Mike, welcome to the show. Hey, thanks for having me, Kevin. Yeah, excited to get to talk to you. Let's maybe start with a little bit about you. Can you talk about your background and then how you got into Homebrew and where we're going to go today? Yeah, sure. So I feel like in tech, I've kind of had two lives, right? So there's my maybe a little bit like being a really rubbish superhero, right? Where I guess my commercial job related life, you know, I'm a guy from Scotland. I had an interest in computers, did the computer science degree thing, got the tech job thing. I've been doing that since 2007, just getting jobs, changing jobs, paying the bills, having fun, all that stuff.

2:01But then there's my open source life, which is generally of more interest to people with homebrew and all that type of background. So my love of open source, I guess, probably started while I was at university. Like I came to university, I heard about, you know, when I was in high school, people talking about installing Linux on the machine the same way that you might talk about, you know, taking illicit drugs or whatever. It was this kind of like risky, dangerous, sort of like somewhat admirable thing. so yeah so i got to university like a bit of a kind of windows power user had not done meaningful programming really like beyond just trying to get games working my computer and you know peer pressure happened pretty quickly and i was like okay i need to get on the installing linux on my desktop bandwagon right so got linux on my desktop machine got like a little home server of an old computer running my parents house so i could like send data back and forward and all this type of stuff and yeah and obviously you know desktop linux one of the nice things about it i mean probably even now it's certainly back in you know 2003-4 when i was first dabbling with it it's like open source is front and center right and you very quickly realize like oh this is like a community of people building a thing and as much as i feel like i'm a consumer and i'm using this thing if i file a bug there's a very real chance that like the guy or girl who wrote that is the person who responds to my tickets so yeah so i guess that kind of growing awareness i am you know i started like helping out with things and helping out on irc channels and bug trackers and forums and all this type of stuff and then like you know forking stuff myself modifying it a little bit publishing up the changes in case anyone cared but yeah but i guess for me the the main thing was probably like i did google summer code back in 2000 and what would it be 2007 for the kd like desktop environment still around and yeah and i basically sort of fell in love with the open source community through that really like from spending a three-month project just writing lots of codes seeing very high degrees of trust and mentorship and help and whatever and then i just went on from that being a huge proponent of it in my work life and then I guess the two streams probably crossed again in 2009 I was in London working for a stock called Mendeley across the other side of London friend of a friend was a guy called Max Howell who was also working in London a huge stock called Last.fm that probably brings back memories for a certain number of people and yeah so he had been tasked with you know doing various bits and pieces and building desktop of applications and i believe the the the official story is like he was in the pub one night complaining about all the package managers being terrible and someone said to him well if you hate them all so much why don't you make your own one right and he left the pub went down wrote a sort of outline of what homebrew should be started building it uh and then i got involved you know i can't remember what it was like four or five months later kind of heard about this thing it's I'd sort of tried to build something vaguely similar myself.

5:08And yeah, that was, I guess, 16 years ago, like in September, I've been working on this thing. And yeah, and that's my open source story, I guess. That's awesome. Yeah, I feel like a lot of us have that experience with open source of like, this stuff is all crap. Wait, with this stuff, though, I can actually do it myself and make it my version. Yeah, totally. So I feel like in today's age, especially with Macs having become, at least in the US, and much of Europe, the sort of de facto development environment for many, many developers. A huge number of our listeners are probably homebrew users, but I don't know how many of them have actually looked below the hood at how it works or why it became the de facto norm.

5:52Why is this one not terrible the way that all the package managers that Max was complaining about are? So how would you describe like, what are the core like choices or approaches that have made homebrew so successful yeah before we get to that i just noticed this is again i've been working on for 16 years it's the first time i've ever thought of this i think because you were saying in that sentence and you're talking about max the apple computers and max the creator of homebrew and it's only just twigged i'm like oh yeah that's a fun little coincidence that that is a fun one yeah but anyway yeah so how homebrew works so i think one of the things i've found in my career in general right is i'm i'm a maintainer i'm not a creator right like i'm someone who is very good at taking something that someone else has made and riffing off it and evolving it and growing it and blah blah blah but like i am rubbish at coming up with new ideas myself right so a lot of the kind of brilliance of homebrew i think goes back to max's original design right and i think the i guess the less interesting parts of the design first but people might not know this so let's let's tell them anyway so homebrew is and was from day one written in ruby primarily and so like at the time you know ruby was sort of starting ruby and rails were starting to take off ruby was like a very you know becoming a popular language in 2009 um and you know nowadays it's the same you know there's still a bunch of code that probably goes right back to the first kind of few commits and if you sort of squint a little you can see that you know the dsls and stuff that are being used in Humblew today are still much the same as back then.

7:28So I think that brings you to the first part of Humblew that I think was initially brilliant, which is like something Ruby is very good at is building these DSLs, domain-specific languages, I guess we would call them, where because Ruby code can be at least made to look very much like just normal English, right? And because Ruby is a very low syntax-heavy language, you can build these things that look a little bit more like you're just declaring, you know, it almost looks a little bit like YAML without as much indentation and stuff sometimes where you can just look like you're declaring data, but you're actually calling functions inside a class and things like that.

8:09And as a result of that, Hubru started off with these things called formula. So the formula is basically like a definition of how a package is built. Originally, Hubru started off being a from source package manager, so everything's built on your machine. nowadays basically everything is built by someone else usually homebrew somewhere else elsewhere but that kind of initial formula description was very very easy to read and write and contribute to so i think that was a key thing to begin with like if you've ever worked with other package managers particularly back in that era and had to like package something in you know app get or rpm or whatever like it was a nightmare frankly like it was horrendous how many steps it would take and how many things you'd have to do to pass all the lints and test all this stuff on your local machine whereas the ruby formula made it very easy to read and understand what's going on and design and contribute and that's the next thing i think that was the really smart choice It's like I was speaking with a CEO recently who said something along the lines of, you know, all the best engineers are lazy, right?

9:16And often engineers that he might have a problem with are the ones who are being insufficiently lazy, not working hard enough. But like there was a certain amount of that from the outside with Max, right? Where he said like, hey, like, you know, if this package manager is going to be successful, we're probably going to have like five, six, 10 ,000 packages. I don't want to maintain 10 ,000 packages, right? I also don't want to go down the route of something like Debian or whatever, where I have to find 1 ,000 people who are willing to maintain 10 ,000 packages. So this was around the era that GitHub was starting to take off.

9:51So he basically was like, right, we're going to design the package manager. So it's a GitHub-based workflow. And Homebrew actually predated pull requests even on GitHub. So the original flow, I mean, the first few commits I had would be, I would be on IRC and I would DM Max with like a commit in my fork. And he would be like, yeah, that looks good. He would then cherry pick that from my fork and then push that to the homebrew repo. Right. And then over time we ended up pull requests and reviews and all this type of good stuff. But yeah, I think that model from the outset of designing it to be both very, very easy to contribute to, but also designing community contribution and community maintenance as being a core part of the overall flow of Homebrew is, I think, what resulted in it being as successful as it's been.

10:39That's fascinating. And I think for open source in general, the packages that sustain themselves seem to be those that manage to build that community early. So thinking about that from the beginning is great. Another thing that I think makes Homebrew different from at least the package managers that went before in MacLand and also a lot of the Linux package managers is it's pretty much all user space, right? Yeah. So that's one of the nice things about macOS and one of the reasons I'm still a fairly diehard Mac fan today is back in the Linux package manager days when I was working with that, I mean, the Linux package managers, I would still say to this day that I don't think AppGet is better than Homebrew in every way.

11:27but I think overall it is a more powerful package manager right it has a lot more stuff a lot more sorted than homebrew does right um but it it always there was a slight weirdness to me always where essentially like some random utility that I'm pulling off someone's github right that i essentially if it breaks it has no consequence to me like and my libc or like kernel are essentially managed in exactly the same way as far as the package manager is concerned right and one of the nice things about mac os or i mean even nowadays again if you sort of look at it from a funny perspective things like wsl or like there's linux distors that are doing this now as well you have a kind of a mutable file system like a modern mac os does and homebrew linux is taking off on those as well is this idea that like as you say you have this user space package manager right which is living in a non-protected part of the file system you don't need to run sudo to run it and stuff like that once it's installed and then basically you sort of limit the the damage that that can do to your system and nowadays i think partly because of maybe homebrew becoming more popular like the you know the mac os base system is like super locked down and you can get access and modify things if you want to but you're gonna have to boot your mac in a special mode and blah blah and that basically just means that developers on macs now don't have to like fiddle with things in user bin user bin is up to apple like opt homebrew bin is up to homebrew and you can just remove Optum Rubin and every at least like desktop application on your system should just continue to work fine as is.

13:24All your programming projects may explode, but it has less of a degree of concern that you're actually gonna like break your system or whatever, which was at least theoretically possible in the battle days. Yeah, well, and it makes, for example, staying up to date with Apple's upgrades it's a lot less painful as well. I feel like it used to be I would, and I still have some of these instincts, but I would resist forever upgrading to the newer OSs because I knew my whole dev environment would break and I'd have to go and rebuild everything. And I feel like that problem has more or less gone away.

13:58Yeah, so I'm glad to hear your perception is that problem has mostly gone away. I mean, to be fair, Apple are better on some of the stuff than they used to be, but it's definitely an area of pain that projects like homebrew mainly feel but in some ways like if homebrew can do one thing well it's providing a abstraction layer over all of this stuff so that we have to care and worry about and fix this stuff and you don't right so yeah like that's that's very much a a goal of our package manager is to i wouldn't say it's completely painless at this point but it's i I mean, it used to be days and now it's like, oh, I've got a couple hours of cleaning things up.

14:42Yeah, for sure. Let's maybe actually then peel back that abstraction layer a little bit because I as a user, I just know the APIs you provide. But what are actually the key pieces that go into making a package manager work? Yeah. So I think Homebrew is a bit of a special snowflake of a package manager in lots of ways. I guess I've mentioned some of them already. you know some of the package managers that have come after have really leaned into the same sort of model of community contribution and stuff like that some haven't i think one of the things we do that often surprises people is you know we have i guess our our stats and best estimates or whatever are like you know five ten million kind of relatively active users of home group which is a scary amount of people um and then in terms of maintainers we have like 30 people right and And probably on a day-to-day basis, probably 10 to 15 of them are active.

15:37And you tend to have this parallel function of even within those maintainers, there's some people who do a really disproportionate amount of the work. And in the total history of all of whom were maintainers ever, I think there's been probably less than 16 people, maybe even less than 50 people. So obviously, that's good scaling, right? Like how you can get a relatively small number of people to provide that amount of service. some of that is the contributors i mentioned before like you know getting third parties to go and help and submit changes probably got like yeah i mean definitely over 10 000 contributors i don't think we're anywhere near to 100 000 but you know in the five figures there but still there's like you know there's scaling effects and you're like how can you make that happen for 20 000 packages which are getting probably you know 10 20 100 updates a day across that so something we have done certainly at least from the very early days of me being involved with homebrew is going back to what we said before about laziness like i'm an exceptional lazy person i like the people i work with to be lazy and i really encourage that right so my one of my positions for a long time which is kind of funny now we've got ai because it's you know encouraging you to think about that in a different way still was almost like i guess i wrote a blog post about this called robot peasantry human empathy right because at the time i felt like i was seeing you know people were almost being like oh i'm gonna write a bot to thank first-time contributors to a project or whatever and like i my observation was is that like if people have a bot doing it it doesn't mean anything they don't really feel valued and considered by a bot right but like on the flip side people are very tolerant of bots being i don't know if you've ever had one of those pull request reviews in a work environment or whatever that are brutal yeah well not even brutal like i would say like excessively pedantic right we're saying you're using semicolons in javascript the way that they don't like and you did it 20 times and they go through and on every single occurrence they're like use semicolons of use different and like when when a human does that you hate that person right whereas when a what i would call a robot or like a ci job or a linter or whatever does it, you're like, that is actively helpful.

17:53And if you didn't tell me all of the occurrences, you would not be a useful tool. So something I try to encourage in myself and in others in Humbroo from the early days was being like, okay, anytime you are regularly making the same comment on say three pull requests, figure out a way to turn that into an automated check that can run, that can make the CI red so that the user has that indication that there is a problem here. and I guess there's, you know, to adopt horrible tech industry jargon, like shifting things left as well, right? So also that idea of like, okay, ideally we move from a human comment to being a CI comment, like on a pull request or whatever.

18:35But then ideally still we move from a CI comment to a local development environment comment. So again, we have a bunch of automated checks. So the most common linter in Ruby land is a tool called Rubocop. So we now have it configured so that if you open Homebrew in VS Code, you'll get prompted to install the RuboCop plugin. And if you install that, then when you're writing Homebrew Code, we will pop up straight in your editor and tell you, like, this is against, like, essentially the description of this formula is not in the format we like. Like, you have started with A or N, and we don't like you to start with A or N because it doesn't look nice in our output or whatever, right?

19:14So then you can have a user who's working on this for the first time who gets that input straight away, right? And if you've enabled auto-formatting in your editor, then some of those Rubicops have auto-correction. So you could start your description with an A or an N. I can't remember whether this one does auto-correction or not, but we'll assume it does for this anecdote. You could type that in and you press save. And if you've got format and save enabled, then you'll just see that text just disappear, right? So obviously that contribution experience is delightful when all the stars align and all that stuff happens.

19:44and instead of a human being like don't do this don't do this your editor is automatically do making your codes the way we need it to look so it passes ci and even if it does make it to ci again like we have a pretty time zone distributed team now so we probably have decent follow the sun coverage but like before we had that there was something really delightful about seeing someone open pull request see you know our linter spits out 10 warnings they read them all they action them all they improve everything and then you wake up in the morning and you're like oh this there was 20 things i would have said on the first version of this pull request instead our ci tooling and the robots or whatever settle this the person's got it ready and now i can just merge it straight away right and then everyone has a better experience and that's how the projects can scale dramatically better in that way and i also might you know while i'm on my soapbox like my personal experience is a lot of companies could do with moving a lot more in that direction than they think as well.

20:41Because generally, humans don't like doing that stuff. And generally, pretty much every software company in the world, if you're like, I can give you a way to move faster without negatively impacting your quality, like most people or most companies, most developers would say, yes, please. And that's how you get there. You get there by very heavy but reliable automation. Have you tried building a text-to-SQL chatbot? If your AI agents don't understand your data, its definitions, queries, and lineage, they're forced to guess. And bad guesses mean risky assumptions. That's where SelectStar comes in.

21:19SelectStar automatically builds an always up-to-date knowledge graph of your data, capturing metadata like lineage, usage, and example queries. So whether you're training an AI model or deploying an agent, your AI can answer with facts, not assumptions. Stop the wrong SQL queries before they happen. Learn more at selectstar.com. There's a mindset shift there that takes a while to sink in. And I find I'm climbing that whole mental climb again now with these AI coding tools because there's things they're good at, there's things they're not good at. But a thing they are very good at is writing tools.

21:56So you can use them to automate your check that you are going to do. and it's mind-boggling how much faster you can go as you accumulate those i'm in the same space right now where i would say i'm a like ai i don't know user and mild optimist but it's like figuring out the places in which these tools are very well suited and very badly suited right because it you know it's like the that old expression used to be of i can't remember where i first heard this but you know like your your average not tech person would be like i hate computers because they never do what i tell them to and then the tech person responses no you hate them because they do exactly what you tell them to when that's not what you mean right and i think it's interesting because i feel like a lot of the time the some of the modern lm tools are getting better at inferring what you meant rather than what you told them to do but then on the flip side, the responses are now non-deterministic.

22:56So you can't, you know, that, there's examples before with the CI and the linting or whatever, I'm sure I could describe in prose and feed that into ChatGPT and have that somehow run in my CI pipelines. But the problem is if you rerun that on the same code three times, you're going to get, like, you don't get the same response every time without some sort of deterministic, like, code layer living underneath or on top that is making sure that that stuff works as it does. So yeah, I still feel like that's a big point of growth that we're still figuring out is like figuring out how do we make these two tools play together in the nicest possible fashion.

23:34The automated validations that you're doing are actually great for that. Because if you can put this non deterministic thing in a loop with deterministic validation for correctness, your quality gets so much higher. Yeah, yeah, I've definitely felt that When I've been doing stuff, I'm yet to really go hard on agentic stuff, particularly agentic, not in a window in the foreground sort of approaches. It's on my to-do list to play around with that in the next few weeks. But even on that, I definitely find in tools like Cursors, Agent Mode, or whatever, if you can say, here's how you run the test, here's how you link the code, here's how you type check the code.

24:14So Homebrew nowadays uses Sorbet, which is like a type checker built by Stripe kind of type checker runtime type system, runs exceptionally fast to kind of check the entire code base. then yeah like the more of those guardrails you have then the better these tools do because they're able to validate their own behavior without you having to say like oh no that should be you know like an integer being passed this method not a you know a number one in quotes or whatever so let's come back a little bit to the pieces that make homebrew work so we talked about kind of the automations for contribution and the key sort of piece of formula which are building dsls what's the engine inside of homebrew presumably you have some sort of dependency resolution or thing like that going on and like what are the like i don't know the software architecture of a package manager yeah so i mean i don't know that i know the software architecture of package manager either but i can speak to yeah homebrew basically where you touch upon dependency resolution that's the most common thing that you know the of value in some ways that a package manager is providing so So if you don't use or have never really thought about a package manager before, essentially like the two key things you might say that they are doing for you is one is just the way of essentially specifying, here's a bit of software.

25:37I want this installed. You figure out however that gets installed. And the way of indicating you want two pieces of software installed should be the same, even if the underlying build mechanism, distribution mechanism, whatever is radically different between those two things. So it's that abstraction layer. Generally, as well as that, there's some sort of version-based behavior as well. This is something where homebrews got a lot of flack over the years and were better than we used to. But again, let's differentiate between different types of package managers for a moment, right? So you have, I guess, what you might call, I guess you were saying user space earlier.

26:17Some might say like system package managers, right? which would be Homebrew would be sort of an example, but definitely something like Appget on Debian or Ubuntu, something like Yum or whatever on Fedora, I think that's been, or DNF maybe now, I can't remember, it's been a while, Emerge on Gen2, Pac-Man on Arch, et cetera. So those are responsible generally for installing everything that might be on a system or not. And like, again, you can debate whether Homebrew is one of those or not, but what Homebrew is definitely not, which people are often more familiar with, is a language package manager.

26:52So say something like NPM or Cargo in Rustland or PIP in Python land or GEM or Bundler in Ruby land, et cetera, et cetera. These package managers where everything you install through that thing will be written at least primarily in that language. They may also have C extensions or whatever, depending on the language. But essentially you're installing libraries mainly for the writing software yourself in that language. Right. So one of the big differences between the language package managers and the system package managers is the language package managers generally have this model of like, okay, well, we basically can let anyone sort of publish anything.

27:33And ultimately the people who are in control of uploading a new version and deciding whether people get upgrades or not are the publishers of that package and generally the authors and the creators and the repo owners on GitHub. Whereas with system package managers, generally there's a bit of a like, okay, because of the dependencies, which we mentioned earlier, you need to verify that it is okay for everyone to get a new version of a thing, right? So if I decide I'm going to, I have some library that a thousand packages in Homebrew depend on, I release my version two and I say, okay, Homebrew, right, we're ready for version two of the package, right?

28:11Like if I'm in entire control of that, happening then again depending on the package manager like that might be okay it might be that they can just upload version two and then everything sticks on version one until we manually like change it and it says it goes to version two so homebrew was designed from the early days to be again more package manager terminology i'm afraid what you call a rolling release package manager so things like ubuntu or debian you might be familiar that they have every so often they've got you know i can't remember what an ubuntu one is but it's you know like poetic pelican or you know it's always like a you know two letters the same or debian buster or whatever right so they generally the way they do that is they say okay we're going to like branch off a while before we essentially get all the packages so they're like vaguely stable together and then we have a point where we say okay we've released this new thing we basically are only going to do security updates and bug fixes until there's ways of you working around that.

29:14But by default, that's how we're going to do things. Then you have a rolling release package manager, which is what Homebrew is, which is essentially you get the newest version of everything all the time. So if you just type brew install some package name, say MySQL, right? In Homebrew, at least, let's simplify things and look at Homebrew 10 years ago to start with. If you type brew install MySQL, you will always get the newest version of MySQL, right? And if yesterday, whoever it is that owns MySQL nowadays, Oracle dropped a new major version and we're on MySQL 10 and it has no backwards compatibility with MySQL 8, right?

29:50Like, tough luck, right? Like, all your shit's broken, but Homebrew is internally consistent, so it's fine. We evolve from there to being like, okay, well, then we're going to at least have CI where we're going to test and make sure that everything works within Homebrew's ecosystem, at least. So you're not breaking any other packages in Homebrew. That's one of the fun artifacts of our CI is that when that happens with something like OpenSSL, which has thousands of dependencies, what that looks like is a CI job that will take two to three days to run of continuously churning away for like, you know, 48 hours.

30:28We've had various CI providers and hosting providers who assume that that's a typo. where we say that like, hey, like your timeouts are triggering too long. You know, they're kicking in after, I think like one time it's like, we're kicking in after 48 hours. And they're like, oh, do you mean like 48 minutes? No, 48 hours. Like, yeah, that's, surely it's not taking longer than 40. No, yeah, this job takes up to 72 hours to run. So that's been a little bit of a surprise. And again, that's part of the reason why people, when they might critique Humboldt and Humboldt's model, it's like, yeah, like this, it's hard to do this stuff at this sort of scale.

31:04And then more recently, Homebrew has done a bit more around versioning. So now you can install MySQL at 5.7, and that means that you will sit on that version forever. But because of Homebrew's original architecture, the way we do that is we maintain a separate MySQL at 5.7 package, and we have to maintain that indefinitely. And if there's something that has to happen to all the MySQL versions for a new Mac OS version, we have to essentially port it between all of those, right? So there's a little bit of overhead there, which is why we don't do this for every single package all the time. Yeah. Capital One's tech team isn't just talking about multi-agentic AI.

31:45They already deployed one. It's called Chat Concierge and it's simplifying car shopping using self-reflection and layered reasoning with live API checks. It doesn't just help buyers find a car they love. It helps schedule a test drive, get pre-approved for financing, and estimate trade-in value. Advanced, intuitive, and deployed, that's how they stack. That's technology at Capital One.

32:07You're a professional software engineer. Vibes won't cut it. Augment Code is the only AI assistant built for real engineering teams. It ingests your entire repo, millions of lines, tens of thousands of files, so every suggestion lands in context and keeps you in flow. Where other tools stall, AugmentCode sprints. Unlike Vibe coding tools, AugmentCode is built for shipping to production. And you don't have to switch tooling. Keep using VS Code, JetBrains, Android Studio, or even Vim. Don't hire an AI for vibes. Get the agent that knows you and your code base best. Start your free trial at AugmentCode.com.

32:47So that is interesting. So what CICD provider are you using today? So nowadays we use GitHub Actions, but we have our own self-hosted runners for doing a lot of the hard work, basically. So particularly on macOS, essentially we need the newest version of macOS pretty much as a month, two months before Apple released the new version, because we want to be able to test things and verify things or whatever. and we are yet to find a, we would ideally use an entirely hosted solution. We are yet to ever find an entirely hosted solution who can do things as fast as we need them to be done, but also provide like, you know, 72 hour timeouts on things.

33:34So our self-hosted runners used to be, again, like a little bit of fun open source lore, used to be physical Mac minis that were originally installed in a data center by me taking them down in a suitcase from Scotland on a train, which ended up going in the car of someone whose podcast I listened to who let me stay in his house and then put them in the data center of his ISP. And then later I took another train and then moved them up back to Scotland and blah, blah, blah. So yeah, there's a bunch of funny games that happens with this before this stuff was available by cloud providers. But nowadays, there's a company called Mac Stadium, who we've worked with for a long time now, probably coming up to 10 years, who provide like hosted Macs for us to use.

34:23And they've got like a nice sort of Kubernetes like abstraction layer that lets us kind of spin up and spin down VMs of the various macOS versions we need to run. So, yeah, so that's basically what powers are like CI, like the actual where the code is being run and built side of things. But yeah, but then the main almost like centralized server now is all on GitHub Actions. Who funds that? Do they donate those resources? So originally, Mac Stadium donated all of the resources. And then Apple helped when we were in the Apple Silicon transition. That's the first time, I guess, Apple like gave us something, which was nice.