Subscribe
Share
Share
Embed
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
SITC-Mike McQuaid
===
Mike McQuaid: If you want to release a new version of your package or whatever, we, yes, we have lots of automate update tooling or whatever that might pick that up, but the process of like actually getting that out to users. One of our humans is always looking at that and saying, yes, this looks fine.
Corey Quinn: Welcome to Screaming in the Cloud. I'm Corey Quinn, and today's guest is one of those. He, or at least his work needs no introduction to most of us. Uh, Mike McQuaid is the project leader for Homebrew. If you have not. Been become acquainted with Homebrew. You either have been living under a rock for 15 years or alternately you probably don't touch Mac Os, which is like living under a rock for the last 15 years.
Mike, thank you for joining me.
Mike McQuaid: Thanks for having me here, Corey.
Corey Quinn: This episode is sponsored in part by my day job Duck. Bill, do you have a horrifying AWS bill? That can mean a lot of things. Predicting what it's going to be, determining what it should be, negotiating your next long-term contract with AWS, or just figuring out why it increasingly resembles of.
Phone number, but nobody seems to quite know why that is. To learn more, visit duck bill hq.com. Remember, you can't duck the duck bill. Bill, which my CEO reliably informs me is absolutely not our slogan.
And I feel like I just misstated already off to a great start because I've always used Homebrew on a Mac, but apparently it supports Linux as well, uh, as a, as a first party target operating system.
Am I misunderstanding something here?
Mike McQuaid: No, it's, yeah, it's been doing that for a wee while. A lot of people are surprised both that that happens. And then generally the next reaction is, why would you do such a thing like Linux has a lot of perfectly functional package managers. Why would you bring your
Corey Quinn: No, it doesn't, it has things like.
Apt and Yum. And now start replaced by DNF. There's, there's always a thing like, uh, it's like Thomas Jefferson once said that the Tree of Liberty must be refreshed with the blood of Patriots, and it feels like generationally we need to refresh package management with a new version to supplant the old one in Linux.
Distros. Every distribution I can think of has gone through this entire process and it shows no sign of stopping. But what's the Linux story for Homebrew?
Mike McQuaid: So the living story for Homebrew, I guess it started out with being a bunch of people in Bioinformatics labs who were like, uh, I don't have Root, so I can't use the assistant package manager.
And if I sort of like fiddle with Homebrew enough, then I can use it to install shit in my home directory. And then like, Hey, presto, fast forward a while and a non-trivial number of people have used it. And the kind of cross-platform nature is kind of. Appealing for some people. 'cause you can have the same package manager commands on Mac and Linux and CI and development perhaps and whatever and all that good stuff.
Uh, and then more recently we've actually seen, like there's a couple of Linux Distros that do the whole, uh. Like immutable root file system thing, and then they use Homebrew, uh, and flat pack as their kind of primary package manager basically. Um, so that's, that's been interesting seeing those like Homebrew being mentioned on the front page of a Linux distro.
That's a. New development.
Corey Quinn: Yeah. For me, it came back for a very simple starting point of once upon a time, back in the day, a Thursday I believe was the day, but that's neither here nor there. And I wanted to, I was trying to copy and paste a command off of Stack Overflow, which was a best practice as is for many of us.
And W get wasn't installed on a Mac and, huh? What's the best way to get this installed? So first I went down the primrose path for a couple of years of playing around with Mac ports because I am an old BSD saw, and I don't believe that Homebrew really existed back in those very early days, but it was just night and day once I first encountered it.
Uh, and it had all the hallmarks of a. Terrible decision. Let's be honest here. Oh, I just copy and paste this Curl Bash equivalent, though we didn't call it back then into my terminal. It'll just do all the magic things it needs to do and set it up from a security perspective. It's something of a nightmare.
Oh, it'll just install the latest version of everything. So what you run today and the new developer runs next week are going to be not exactly the same thing. But it worked and I started using it extensively. I became a, uh, I started doing some of the packaging for a few things back in the day for Homebrew.
I'm running my own tap now with a couple of things that have now gotten enough traction that I probably should prob try submitting 'em to core and see what happens. But everything I've ever really wanted, what lives inside of Homebrew. And when I redid a laptop for the first time in a few years, a month ago, suddenly all the stuff that I installed that were, that was graphic utilities live within casks, which used to be its own separate thing and now seems to have more or less merged into mainline.
What's the history there?
Mike McQuaid: Yeah. So casks were, again, you've probably clicked on, if you haven't already been familiar with Homebrew before this podcast, that we like our beer metaphors over here. Uh, this was partly 'cause Max, the creator of Homebrew, uh, conceived it. While under the influence, uh, after being in a pub in London, whining about package management and having his friends tell him.
Presumably also under the influence, well, if you're so smart, why don't you make your own package manager? And turns out,
Corey Quinn: thank God, usually those drunken, belligerent conversations turn into, and that's how I built a database engine. So at least this one's novel.
Mike McQuaid: Yeah, exactly. Exactly. So casks were, uh, again, you're seeing a bit of a running theme here, like also a kind of side offshoot of Homebrew where some people were like, okay, Homebrew installs, all your nice open source stuff.
Uh, but what if you could use it to just like download Google Chrome and put that on your machine or one password or any of these other things, right? Yeah, so basically like they were running their thing. It got a bit of traction we noticed in the main project and we like brought those people over and, and merged the two projects essentially.
So that's been one of the nice things with home ecosystem is that over the years, essentially. When people do cool stuff that are like broadly in the ecosystem, we try and like bring them into the fold and make it all official. And part of our main thing,
Corey Quinn: which is a, a nice approach, it's, I've also found what I was looking at, the submission requirements recently, that if you have auto updating nonsense, uh, Claude Co is a good example of this.
Uh, it doesn't really belong in Homebrew Core. That's what casks are for. I guess, how do you view doing an installation dance like that where at any given moment what is being installed in your system is not gonna be what it was 10 minutes ago?
Mike McQuaid: Yeah, I mean that's the fun of, I guess Homebrew package management, you alluded to that earlier, right?
We've always been, I guess what you would call in package management, nerd Nerdland, AKA, my life, a rolling release package manager. And what you mean by that is like we. Whenever we get the newest version of stuff, if it doesn't break Homebrew itself, we generally just foist that upon people. Right. So in casks, as you say, there's some more extreme stuff where the cask itself can update auto update.
So Homebrew doesn't necessarily even know the version of the cask that you have installed at this time, but that. We found that works a little bit better than, you know, a lot of tools like maybe Claude Code or Google Chrome or whatever nowadays that end up shipping their own auto update engine and it's like,
Corey Quinn: and there are four releases on day in some cases.
Mike McQuaid: Yeah. And we could try and fight that, but. Again, like, I mean Homebrew in many ways like keeps after me in terms of like I'm exceptionally lazy, right? So it's like if there was some, so say like Debian, right? Debian is a beautiful, morally pure distro and on a lot of this stuff they're like, well, if there's like, there's
Corey Quinn: the kindest way you could have found to put that.
Mike McQuaid: If they're like gone auto update, they're like, yeah, we'll patch out that auto update and we'll just keep patching it out forever or whatever. Whereas I'm just like, eh, that sounds like a lot of work. Like that's. Well if, if that's what the software project is trying to do, let's try and find. A place in our ecosystem that we can slot in and they can do things the way they wanna do it, and we can do things the way we wanna do it, and users can end up ultimately moderately happy.
Corey Quinn: Yeah, I, I prefer being able to do it through Cask just because that way I don't have to crawl across half the internet to find stuff that I care about. The only time I've run into trouble with it has been, oh, there's this thing that I wanna install, forgot I got it from the Mac app store, and that's where the license is tied to it.
So, okay. Now I have to keep a separate exception list for that. Oh wow. Too bad. So sad.
Mike McQuaid: If you didn't know about this already. I'm gonna, I'm gonna transform your life here, Corey. Right? So that
Corey Quinn: hit me with it. Please. I'm about to redo this machine, so tell me more.
Mike McQuaid: Oh yeah. Oh yeah. It's coming. It's coming.
Prepare yourself. So Homebrew has this thing called Homebrew Bundle, which uses brew files, right? And it's loosely based off GEM files in the Ruby Ecosystem order. So what you can do in there is you can specify. Your taps, your formula, which are things that built from source supplied by Homebrew, your casks, your Mac app store apps.
Uh, recently your GO cli, if you've got them. Your Visual Studio code plugins. Someone was proposing adding cargo, the rust package management support in there as well. So that file. Lets you basically be like, okay, you can dump everything you have installed to that file and you can install everything on that file.
Um, and so you could have like a global wide thing. I keep mine in my dot files, and then I also have a little mini open source project. The, the most successful thing I've created by myself called Strap, which is basically like the idea when you get a new computer, you run this one script installs, Homebrew.
It looks on your GitHub. If it finds your DOT files repo, it pulls that down. If there's a brew files inside it, it installs from the brew file. So you basically have like. One command you could just run to basically be like, install all my stuff and get my, all the software on my computer release. Back to where it was before.
Right? So hopefully this is gonna make your new build experience that bit more pleasurable than it currently
Corey Quinn: is. Yes. And the, the counterpoint that I find here, 'cause I, I built a bunch of these things before, uh, this machine has been around for a while. Uh, let me just, for example, run this now Brew list pipe to WC dash l.
I have 365, which is a suspicious number of, uh, packages installed on this thing. So part of me, like a lot of that is stuff I needed for weird one-offs that I no longer need. I honestly, on my laptop I have about, I dunno, 15 to 20% of that where it's, I just, because I just recently did that one and it'll, it'll eventually grow in time.
But I don't necessarily want to have all those things reinstalled. Part of the reason to do a fresh install is to get away from the legacy Croft. I have something like four different ways of managing N VM on this system, which is kind of a problem. I wanna start standardizing around Meison pri, which is I the one that I've.
Found that I like the most these days For Python, it's strictly UV system wide and so on and so forth. A SDF get rid of it because its ergonomics are terrible. I can never remember which command parameter goes where, and they're positionally dependent, which is just wonderful. Simply wonderful. I have opinions and I'm belligerent, and I refuse to learn new things.
I am the worst engineer you've ever met. It's great, but I'm also a typical one.
Mike McQuaid: Yes, I wish I could say that, that, uh, rant was not representative of the typical Homebrew user, but you, you will fit in well with our community of people who do not like it when we change their shit, I guess on that. So while I am evangelizing the Why Brew files will change your life, right?
So if you run brew bundle dump, which dumps all your things out, one thing at least of that list of 365 is that it will only output the things. That you have intentionally installed. So anything that was pulled in, not
Corey Quinn: its dependencies along the way. Yes. By
Mike McQuaid: dependencies. Exactly. Unless you also intentionally support installed the dependency, in which case that it will remember and know to do that as well.
So the little workflow I have after that, like, sounds like you have a, you know, a, a world of craziness to unpack, but maybe on this new build, if you're doing it from scratch, then what I do is I have my brew file. I keep that in my dot files directory, which is a GitHub repository, uh, and a locally checked out git repo.
And then what I do is I just install my stuff and then every so often I run brew bundle, dump dash, just global. Uh, and then I get my brew file in my dot files repo. Is like being nicely replaced. And because it's a GI repo, I don't care that it's being replaced. And then I look through the diff, I do a little local review in my local, get gooey of Choice Fork, which I would recommend.
Very nice little get gooey. And then I'm basically like, which of these do I wanna keep? Which of those do I wanna delete? Right? So I stage it, I commit the stuff that I want to keep, and then I maybe get rid of the changes I don't want to keep. And then after that I can then run Brew bundle cleanup. Which will then use that brew file and then uninstall everything that is not present in that brew file, so then I can get myself from a world of chaos into a world of order and serene.
Package management com.
Corey Quinn: I like this quite a bit. Yeah, honestly, it's going through and like, uh, doing the dump on this. Okay. I've got a whole lot of lines to delete in this, like rust. When the hell am I gonna need rust? Well, the next time I grab something opinionated off of GitHub, but until then I can enjoy not having to build a conference talk as a prerequisite for writing code.
You know, basic stuff in life. I've also seen Homebrew itself over the years has changed significantly, where just even the process behind it, it auto updates now, which I think is great. Your analytics, I think, have been handled in the most user respectable way possible. The, the fact itself updates only intermittently.
Not every time you do stuff that's phenomenal. It seems to have paralleled itself a lot better than it once did. As far as downloads and installs go. Like someone has put some thought into this. There's an entire, there clearly is some sort of dag involved.
Mike McQuaid: Yes, there definitely is the occasional thought that happens, uh, that results in a change.
Uh, s several of the changes you've mentioned are things that people still besmirch my name across the internet for, for ramming home aga against the interest of the users. But the problem is with things like open source, right? Is Homebrew has we gasti. About 10 million users from like analytics analysis stuff where like we don't have, like, we have opt-in, uh, sorry, opt out analytics not opt-in.
Again, another cause of contention, but you, you can sort of infer that the vast majority of people opt. Out, uh, based on the download numbers from GitHub's packages, uh, versus the numbers we get for analytics. So that's our, our rough guesstimate. So for those 10 million people still feels
Corey Quinn: low based upon the sheer number of developers in the world.
Most
Mike McQuaid: of the news, yeah, maybe it may, maybe that's, maybe that is on the lower end. But, uh, the number of people who essentially service their requests for those people are 30 maintainers. Right? So when, when you are dealing with that level of scale, a all glory to. The internet and open source for making that sort of scale even flipping possible, but also you end up having to make nasty little compromises sometimes.
Like say the auto update thing, right? Lots of people really hate that, but what it stopped was 95% of issues being this thing is broken. Run brew update. Does it still happen? Oh no. It's fixed now. Right? And there's only so many times you can, uh, respond to that and not write an auto updater before your brain just turns to pulp.
And my brain was starting to turn to pulp and auto
Corey Quinn: update bugs are the worst. 'cause how do you fix them?
Mike McQuaid: Well, yeah, that, that's the other beauty. Yeah. Is when, when you break the auto update, which I have done once, that is a whole new world of pain as well, where it's like, but I, I did everything you said.
I ran the updates. Uh, yes, but the update is broken so you can't run the update because the update won't update the updates. Uh, and neither will the auto update update the update. To run the updates, you have to run another update to update this. So now whenever anyone who's gonna help my
Corey Quinn: mom with that, her, nothing was working in her browser anymore, turned out it fell off.
That Google Chrome update path doesn't like four years
Mike McQuaid: beforehand and sadness. Yes. And, and this is why like I break out in hives anytime anyone submits a pull request, changing that auto update file, because I'm just like, are you sure? Are you sure you really want to do this? Do you really wanna roll the dice and be the person that breaks the auto update?
Because I've been that person and it sucks.
Corey Quinn: Yeah. But, uh, suddenly on the plus side, once you do that, everyone knows your name,
Mike McQuaid: one way to become famous or infamous, I guess.
Corey Quinn: Yes. It's Do you find that people tend to pin particular brew releases? Uh, I'm sorry. Package releases inside of brew, like, oh, always install this particular version of this package.
Mike McQuaid: Yes, sometimes. So we, we have like a pin command that lets you do that, but like the usability around that is kind of like, blah.
Corey Quinn: Only time I've ever used it has been in highly prescriptive, here's how to install a dev, uh, environment in old school stuff before the advent of docker.
Mike McQuaid: There. There's a bit of that.
And also like, what we recommend nowadays is like there's, we provide. Version packages for some stuff. So if, if that's available. So say like, it used to just be, there was just Postgres, right? And then Postgres got a new, made your version update and you wanted to set an older version of Postgres. Sucks to be you, right?
Like, and then we had a slightly more middle ground now where it's like, okay, now we have Postgres. I forget the versioning scheme off the top of my head, but whatever it is, Postgres 18. Postgres at 18. Postgres at 17, Postgres at 16. Right? And you can choose to jump your way between those different packages.
Right? And for a lot of people, for a lot.
Corey Quinn: But just installing Postgres is the latest stable.
Mike McQuaid: It depends, uh, I think Postgres is a special case 'cause we're still dealing with some issues there. In In general, yeah. In situations where it's like, I need this exact version. I need Postgres, not 18, not 18.1. I need Postgres point 18.1, 0.3, because that was the best version ever as a particularly fine vintage that year.
Then what we recommend in that situation is like. There's a command called Brew Extract, which then pulls, uh, Postgres out of our repositories and then gives it in your own little GitHub repository for a very specific version. And you have ultimate control over that, and you can choose what to do, and then you can live in happy, stable land.
So that, that's generally what we recommend. It's a little bit more work, but we do provide a bunch of helper commands and whatever. As you may notice, again, there's like a brew command to do just about everything, right? So like. Even within Homebrew itself, the way we run the project, like we give our maintainers who are remain active 300 bucks a month.
Uh, if they are like regularly contributing to Homebrew, which probably contributes about as much money, probably less than your average like paper boy or girl gets when they're 12 years old going around the neighborhood. I think that's the going rate for a open source maintainer nowadays. So, yeah, not a lot of money, but like we have to have a way of figuring out, oh, if someone was on a away for three months, like.
Do they earn that or not? So we have a Command brew contributions, which looks at the contributions of the various maintainers in that timestamp, right? So essentially, almost all of our tooling by default is public, right? And that little tool I use to figure out who gets 300 bucks in a given month or a quarter or whatever, right?
Anyone can use that and you can run that tool and. In fact, there was a bunch of brew I
Corey Quinn: yelled at just now saying, your token needs the read org scope to access this API.
Mike McQuaid: There you go. What a beautiful error message. If I did say so myself
Corey Quinn: at least tells me I don't have access to a thing, which is great.
Uh, brew doctors spits out three pages of nonsense because I've. I had this machine for too long, which tells me that if ever I need to report a bug against Homebrew, I've got some housekeeping to do first because everyone will blame this like un brewed files in certain places from all the various things I've used, apparently Postgre Squeal 14 is now deprecated.
Ha. Some installed kegs have no formula, which that's novel. I dunno where those came from. Uh, a bunch of casks are deprecated, et cetera, et cetera, et cetera. Like this is what happens with five years of crt.
Mike McQuaid: Yep. Effectively, you've had your yearly health check and the doctor said, how the hell are you still alive?
Man?
Corey Quinn: Your blood type is chunky. Yes. Yeah, it's not going super well here. It's so great. It's, it's time to wind up basically rebuilding things from scratch, but that's. That is the nature of the beast on some level. I've also found historically that having a bunch of deprecated stuff or packages you didn't, you installed, then removed in some district, some package managers could lead to security issues.
Uh, apparently for a while on one of my test boxes that I used as a dev box, it used it set up a poster, squeal user with a password poster squeal. Then I uninstalled the package, the user hung out. So suddenly I had a problem there.
Mike McQuaid: Nice. Yes.
Corey Quinn: Yeah. Yeah. I felt real smart after that one. I've also found that you folks are quick to update where the day of a new Mac os release, suddenly I'll get error messages that I'm not, I have not installed the latest version of Xcode.
It's like, well, that's great. It's been out for 20 minutes. The mirrors themselves do not have it yet, but it's already telling me that, Hmm, you need to update your stuff if you wanna be supported. It seems to have backed off from that jumping the gun mentalities last few releases, so someone's paying attention.
This episode is sponsored by my own company, duck Bill. Having trouble with your AWS bill, perhaps it's time to renegotiate a contract with them. Maybe you're just wondering how to predict what's going on in the wide world of AWS. Well, that's where Duck Bill comes in to help. Remember, you can't duck the duck bill.
Bill, which I am reliably informed by my business partner is absolutely not our motto. To learn more, visit doc bill hq.com.
Mike McQuaid: We try to be like aggressively chill, right? So because we're a bleeding edge package manager, we tend to attract the users who have that. So generally there's like. A little, almost like internal Homebrew bingo about like how soon after the next Mac West release gets announced until, until Apple says the developer beta is coming until someone opens an issue on Homebrew saying this doesn't work yet.
Right? Like, I think we've literally had about 20 minutes. After the keynote ends, someone's like, yeah, why is that? Why is this not working? It's like, 'cause we haven't downloaded it yet. Your dummies like, chill your boots. Like, but yeah, so we, we tend to do a little bit of that ourselves where I guess we're maybe unlike some software where what we try and do is we're like.
We're gonna warn you about anything that might be a problem. Right? And like, if you're not getting any warnings from Homebrew at all, like you know that you have been a good little boy that day, right? And
Corey Quinn: or if not properly installed
Homebrew,
Mike McQuaid: or not properly owned until Homebrew. Indeed. But yeah, so like our, our kind of like brew doctor command, I feel like we were one of the first.
Things to do that, like what we're trying to do is provide,
Corey Quinn: it was the first time I encountered back then most other things called it pre-flight.
Mike McQuaid: Yeah, exactly. So we just try and provide a lot of pointers for like, look, if something's broken and someone's not, particularly in the early days of Homebrew, it's like maybe no one's awake to help you.
Right. And you want to get this fixed in the next 12 hours. So. Here's some stuff you can try, right? Like,
Corey Quinn: I mean, I used to be a, uh, part of the CentOS project. This was back when I was free, no network staff. IRC was the way that I encountered a lot of this stuff and got support for it. And there's one thing that I learned, and that is people are freaking terrible at asking for help in ways that makes sense.
So having a. Doctor command that will identify all the issues with it. And it, it's almost, it, it's close cousin to a diag, uh, spit out where it's like, okay, what version of Mac os? Oh wow, I didn't realize numbers went that low. What else is going on with this system that otherwise they'd have to tease out of people over a period of hours as they start trying to figure out how their system was put together.
Mike McQuaid: Yeah, it's funny, so like GitHub has, Homebrew is one of the first users of like the GitHub issue templates, right? Where you have like mandatory information you have to fill in. But a part of the reason I think GitHub even has them is because when I was a GitHub employee, I whined about wanting those templates so incessantly that I feel eventually someone just gave up and was like, right.
Mike, if it will make you shut up, we'll build these stupid issue templates and no one's gonna use them. And then turns out everyone uses them. But anyway, so like, it,
Corey Quinn: it's a terrific gen AI use case too. Uh, I found,
Mike McQuaid: that's exactly what I was gonna say. Yeah. Like, so we, we found, we found them great for that because, so our, and again, our issue template was basically based off, and I, I used to have like a text expander shortcut literally for coworkers when people would basically ask me for help in a very unhelpful way.
And I'd be like, okay, what did you do? What did you think was gonna happen? What actually happened? Tell me what I can run to see the same thing on my machine. Right? And if you could do those four things, then like, Hey, we've got a great bug report. And also as you say, like for Gen ai. So if you could say the same thing like, a lot of the time, like copilot will like one shot though.
If, if it's completely a hundred percent reproducible and it's well explained in the issue, like copilot can go, okay, run this command, got this output, change some code, run this command until it gets the right output and then ta-da. Here you go. There's a PR and the code quality might be garbage, but.
Often it, it gets a decent amount of the way there if it, part of that
Corey Quinn: is the stuff you never see. 'cause I used to do that by hand. A friend ran ask me better.com, which asked those exact questions. There was no real submit button on it. But by the time that you wrote that out and became with a repro case, you realized you were the one that forgot a comma or something weird had happened and oh.
I misread the documentation, like the best requests for help that I ever written are the ones I never submitted anywhere, because it's solved my problem going through that process
Mike McQuaid: a hundred percent. And that's, that's a big part of the goal as well. Like, and ironically, the people that find those. Flows to be overly prescriptive are often the same people who if they slowed down and ran the flow, they might have avoided having that issue in the first place.
Corey Quinn: What's the security posture on this stuff look like? I mean, I know that at this point enough people use Homebrew that if I can compromise the w get package, for example, suddenly everyone's gonna run the code that I want them to run. What are the safeguards on this? I know that, uh, PI Pi, pi, PI, whoever they pronounce it, I get yelled at if I say the wrong one, but I can't remember which is which.
Uh, they have an entire security team that books at this top. It's
Mike McQuaid: PP, right?
Corey Quinn: Yeah. That's what I'm gonna go with that. I'm sure that Mike Feeder, who runs that will not punch me in the mouth the next time you sees me.
Mike McQuaid: Yeah. So like, we're lucky in ho Brew land in the r. Trust model is very different to pipe IPP, whatever we call it.
Uh, MPM, Ruby Gems, et cetera, right? So those package managers fundamentally have a trust model of we will trust. People to do some verification of the people whose stuff they download. Right? And we will not be a gatekeeper, middleman, whatever, unless it's like gratuitously obvious that this is malware or whatever, right?
That I'm sure some of those folks would say, that's a gratuitous simplification and I'm being very meaning unfair or whatever, but, oh, well that's, that's me. Whereas in Homebrew, every single change that happens in Homebrew. A, a human homebrew maintainer has to verify that, reviews the code and says, this looks okay.
Right? So if you want to release a new version of your package or whatever, we, yes, we have lots of automate update tooling or whatever that might pick that up, but the process of like actually getting that out to users. One of our humans is always looking at that and saying, yes, this looks fine. Right? Uh, and same deal with the way we kind of build packages and things like that.
Like we operate our ci like we were pretty early to the party of having essentially binary packages built from users, pull requests on GitHub, and then just deployed straight out to users, right? With. Again, with human intervention, but like as a result of that, we have built everything with a trust model that essentially you can't trust anything ever.
Right. And all of our CI workflows. Essentially treat even the code they're running most of the time as like untrusted input. Right? So we generate, you know, for example, when we generate a binary package, we then generate JSON that describes the binary package and then later we read the JSON. Because you can't embed arbitrary executable code in the JSO, like you can in the room files.
No, it's like counter talk. Yeah, exactly. Challenge accepted anyone. But yeah, so like that's what we try and do. So like our, our trust model and we are. Lucky enough, careful enough, whatever it may be to touch wood, have not had any major attacker driven security vulnerabilities. I guess if you go through the Homebrew blog, you can see we've disclosed things in the past.
Uh, I think our worst one was based on a Jenkins misconfiguration, which
Corey Quinn: was it called Jenkins?
Mike McQuaid: Yeah. Well, so that's one of the reasons why we don't use Jenkins anymore, because Jenkins misconfiguration was, uh. Rather easy to achieve, I would say. But yeah, like generally we, I think we've had a fairly good track record on this stuff, and obviously as I think Homebrew may have been the first project to create the Carl to Bash pattern, right?
So people are gonna hate us forever for that. But I think in terms of actually user experience, security problems as opposed to just. People in the security community shouting at us and calling us morons, uh, security problems. Uh, I think we're doing all right.
Corey Quinn: Uh, I do wanna ask, uh, before we call this an episode about your approach to open source.
I mean the, the triggering event that's, oh, yeah. I should really talk to you about this. Uh, was a LinkedIn shit post that I did, uh, somewhat recently about. The experience I had when I did a brew install Terraform, and it's like, great, this is an old version because the new versions are not open source license.
SSPL is not open source or BUSL, whatever the hell they're using. And I thought that was a terrific position to take. Some people are whiny about it and I honestly don't care about them because if, why don't you do volunteer work for an IBM subsidiary is one of the dumbest things I can think of to ask you.
Mike McQuaid: Yeah. So I mean our, our view on this is, so what we say in BR is we have BR Core, which was our kind of original package manager, like open source stuff we did. And at some point we're like, okay, we say we only package open source stuff in here. What, what do we actually mean when we say that the nicest definition we came across was the dbn free software guidelines.
Right. And they. Are not, as it might sound like if you're not, someone deeply versed with open source or free software, whatever. Essentially everything within their description is open source and it's a nice, clear definition of things. Right. And there we have a body called the OSI, who we also look to for the advice, who were the one, essentially the body that came up with the term.
Open source back in the day, and I have the controversial viewpoint that words mean things and it's a good idea to make words continue to mean things such as, don't say literally when you don't mean literally, and I will die on that.
Corey Quinn: Figuratively is the word you're grasping for and
Mike McQuaid: Exactly,
Corey Quinn: yes.
Mike McQuaid: So with open source, we have rules on this stuff and when various companies lately.
Have decided to, I guess, Hatchie Corp. Projects as example of one, maybe Redis, maybe Elastic Search, maybe MongoDB when they, as VC backed businesses decide that their business model is not well suited by their current open source license that they have just happened to rely on to get enormous amount of adoption of the last decade.
Right. And they decide that they're gonna change that, uh, and relicense everyone's contributions over that period because they were. Foresighted enough to require everyone to sign over their copyright, which allows them to do that instantly. Hu Brew, various other projects do not do that. Then what that means is that they can do, as you described in that LinkedIn post, a rug pull and everyone's left going, well, wait a minute.
Is this open source anymore? And the companies. Much to my chagrin will say, yeah, oh, yes, yes. This is, this is totally, so we we're just, it's just open source. But, uh, if you wanna make any money, then you need to give us all your, all of your money. But I mean, other than that, it's completely open source, right?
Like it is fine. But again, as I say, when words mean things, it's like, well, in open source you don't get to do that. Right? And. And a lovely conversation.
Corey Quinn: I, I will not volunteer for your pro for-profit enterprise because I won't let people volunteer for mine. Uh, when I contribute to open source, it is open source to which I am contributing, honestly, sometimes to that project's detriment because I'm terrible at it.
But, you know, I, it's not for lack of caring and it's not for lack of philosophical purity. It's, there's a, there's a sense that there are things I will volunteer my time at energy for, and there are things I will do with a hope of making money out of it, and I try not to cross those streams.
Mike McQuaid: Yep. And, and I, I think that's very wise, right?
Like I, I was on a podcast recently with friend Justin Searles, and it was kind of cross pushed to the change log in, which I said like, open source is not a career, right? Like open source is not a business model. Open source is also not a career, right? And I think we have seen a bunch of people conflate these ideas.
You need to pay all open source maintainers and market rate tomorrow, otherwise it'll not be sustainable. And similarly with companies, a company should be able to just release open source software, not charge anyone any money forever. And then like when they get upset that that is not a viable business model, they can change their license and point it the big cloud vendors and say like, well, they're, they're stealing our stuff.
And it's like, well. You, they're stealing your stuff because you said it could be taken. That's what, that's what your license long
Corey Quinn: time like back when there was a New York Times article about Amazon strip mining, open source like that, that's not. Accurate to my mind, they are doing nothing wrong. You can talk about whether they should be contributing back, but that's one of those, uh, appealing to our better angels.
That is not one of those, if they have an obligation to do so. Now, I mean, Amazon does not do philanthropy. Let's be honest with ourselves. They're Amazon. They don't know what that word means, but so, okay. The problem that these companies made is early on, and I, I have some sympathy for it. 2010 or so. Well, we wrote the code.
Clearly we'll be the best ones to run it as a service. That didn't pan out. Now you have people starting open source based companies and they want all the benefits of open source without any of the drawbacks. Like, oh, should never have launched that project with an open source license. Yeah, but no one would've used it if you hadn't.
So what's the story?
Mike McQuaid: And the way I like to deal with this instead, right, is again, blog post I wrote a long time ago, a lot of people don't like me for it, but a bunch of open source maintainers do so worth it, uh, that I titled Open Source Maintainers owe you Nothing. And if you read any open source license, it essentially says, Hey look, if you use my open source and it breaks your computer on purpose, then sorry, you've agreed in using it.
That you waive me of all responsibility for that. So tough luck, right? And to me, the way, if you say, you know, say Amazon, right? Amazon's strip money, my own source, they're using this stuff. Well, what you can do is just, if anyone who is an Amazon employee ever submits an issue on your project, you can go close and say, I don't wanna fix that.
Your company has lots of resources. They can do what they want with their open source project. I'm not gonna help them. Right? You can choose to not accept issues. You can choose to not accept pull requests. You can choose to not. Respond to anyone from Amazon on your issue tracker ever again, if that's what you wanna do, and you as an open source maintainer, have the right to do whatever the hell you want.
And that's, this is the beauty of it, right? And I think this is problem, the thankless
Corey Quinn: job. I've gotta take the other side of it where most of the stuff I write these days, I used to open source all of it, because why wouldn't I? I, I'm sorry, but this way to wind up running a command simultaneously on 15 nodes at once, uh, in every AWS region.
That's not a competitive differentiator. That's just something I want to exist so other people can use it these days. I'll write quick one-offs and I just, I'll keep it in a private repo rather than open sourcing it just because I don't wanna hear it from people.
Mike McQuaid: Yeah. Yeah. 'cause that the, the level of entitlement is often crazy.
And
Corey Quinn: this is a yo low coded thing in half an hour or so. I just want it to work great. I, I know that you have other use cases for it. Go with God, have fun, but I don't wanna hear about it. I don't care. Vibe code it yourself.
Mike McQuaid: Yeah, and And honestly,
Corey Quinn: my coach should mostly be told as a cautionary tale.
Mike McQuaid: The thing is as well, is often the people who are the most entitled about it, ironically, are often the people who are the most reliant on your free gift for them to do their job.
I remember one time we upgraded a version of F fm PEG or changed the codec or something in br, right? And someone said like, I'm running my entire business off this, and you people have just broken my entire business. Like. Have you no shame. And I was basically like, sir, have you no staging environment like you have learned a lesson today about relying on other people's software given freely if, if you're literally running brew update and brew upgrade and that hoses your entire company.
This is what we call a you problem, sir, and not a me problem. I didn't tell you to do that. You decided to do that and now all your stuff's broken like tough, right? If
Corey Quinn: you're running latest or any other bleeding edge package manager in production, it's just a matter of time.
Mike McQuaid: Yeah, and in some ways, again, this, this comes back to what you're saying about the, you know, well we built it, we should be the best to run in production.
It's like, well, no, like you've demonstrated your ability of being very good at running a database open source project, you did not demonstrate your ability to provide a. Multi-region multiculture, like massively scalable cloud provider, right? Which is essentially what if you're offering a hosted database provider in 2025, that's what you're doing, right?
And chances are AWS is probably quite good at that. They probably have quite a lot of people who are quite good at that. And. Again, like, sorry folks. This is capitalism. I don't feel bad that you as a company trying to make lots of money, picked a fight with another company who are also trying to make lots of money and you didn't win.
Like you don't get more sympathy because your code happens to be open source. Right?
Corey Quinn: Oh, for me it's, there's a reason this entire conversation for the last half hour has been about. What we do on developer workstations. I have asked you none of the normal questions. I would if you were building a package manager aimed at, you know, production environments, because I have a whole different laundry list of this.
The closest I run into this is, as I mentioned earlier, well the next developer we hire is gonna have slightly different versions of everything in their environment. Theoretically, I really do hope that the people are updating their packages on a consistent basis. Which brings me to my last question for you here.
Have you ever given thought to having brew auto update on a schedule Bo uh, both itself as well as the packages that have been installed from it?
Mike McQuaid: Yeah, so there's actually, again, a nice little external command for this, which was briefly in the Homebrew system, and then we decided it operated better independently.
Elsewhere. Uh, by
Corey Quinn: then it's not your problem,
Mike McQuaid: sort of Yeah. Uh, by a lovely Shapero called Dom, who used to be a Homebrew container, and it's called Homebrew Auto Update. If you search for that. And yeah, you could basically have that as Aron job that basically every night just in the background will just bulk upgrade everything on your machine.
Right? And if that's how you want to do it, then that's how you can do it, right? Again, another happy middle ground on there, which I quite liked, is if you say using something like Brew Bundle, uh, like I mentioned before. Then you can have through bundle. By default, we'll upgrade all your packages. So if you have a project, say with your coworkers at work, right?
Say you are relying on MySQL and rust and. JavaScript being installed in this like particular project, right? You can have a brew file in your repo route that has those packages in them, and then if someone runs it, then it'll upgrade everything and then okay, you might have someone else on the team who's in an inconsistent state, but then they, they can just run the same command and they will get to the same state so that the state is based on time rather than by, based on a lock file.
But you can still get some degree of consistency there. And also what you could do, which is what I tend to do in those situations, if you want to be like. A step ahead. Say people are not running upgrade relatively often, or you're, you have an onboarding floor or whatever and you don't want it to break.
You can set up a GitHub actions job with a Macs runner that just runs that every night. And then when it fails, it opens an issue or send somebody an email or whatever, and then you know, oh, like something in Homebrew got upgraded and now we need to go fix that. Right. And you can deal with that when you choose to, rather than just like being like, oh, some particular developer ran a particular thing at a particular time.
No, like, come on, people like we, we have ways of solving these types of problems with reproducible environments. Which you can do with GitHub actions. Ta-da. Problem solved.
Corey Quinn: It's, it's a fantastic tool and I wanna thank you for spending as much time as you do on getting it to work. If people wanna learn more, where's the best place for them to go?
Mike McQuaid: Uh, more about Homebrew, you can go to brew.sh um, our lovely domain. If you are interested in the code or contributing, then that will also take you to the Homebrew GitHub repo. Tells you all about getting involved. If people want to see more about me and my ramblings on open source and other things, then they can go to my website at mikemcquaid.com, which links out to all my other internet presences,
Corey Quinn: and we will of course put links to all of this in the show notes.
Thank you so much for taking the time to speak with me. I appreciate it.
Mike McQuaid: Thank you for having me. A delight.
Corey Quinn: Mike McQuaid, project Leader at Homebrew. I'm Cloud economist Corey Quinn, and this is Screaming In the Cloud. You've enjoyed this podcast. Please leave a five star review on your podcast platform of choice, whereas if you hated this podcast episode, please, we have a five star review on your podcast platform of choice, along with an entitled, whiny comment.
That we'll never see because that platform wound up, uh, having their entire stuff go down because someone ran a brew install without any idea of pinning or the fact that this is not how one should run production as a responsible grownup.