Episode 796 transcript

FLOSS-796

Jonathan: Hey, this week David joins me and we talk with John Britton and Mike McQuaid about Homebrew, the package manager that macOS is missing, and Workbrew, the new commercial offering built on top of it. It's a lot of fun, you don't want to miss it, so stay tuned. This is Floss Weekly, episode 796, recorded August 13th.

Homebrew! I'm more of a Whopper guy.

Hey folks, it's time for Floss Weekly. That's the show about free, libre, and open source software. I'm your host, Jonathan Bennett, and we've got something real fun today. We've got, first off, David is in the secondary hot seat, the co pilot chair. He's my wingman. He is the co host today. David Ruggles.

David: I'm holding it down. Yes. I'm holding it down.

Jonathan: Yeah. Now today our, our topic is. Well, it's, it's Homebrew, which is the package manager that Mac OS wishes it had. And neither of us are big Mac guys, are we?

David: Hmm. No I use it. At least once a week, but not extensively. So yes, I have, I have lots of questions that will be the, uh, Luddite.

Jonathan: You're our audience proxy for, I don't know much about this. That happens. That's fine. I have, I've actually used homebrew back years ago we were talking about before the show, I was a part of an organization and someone else that was there was a huge Mac fan. And so they bought some Mac machines. And the whole time I was going, he was.

Associated with the military, so the whole time I'm going, I know he's going to move away, and I'm going to be the one stuck administering these machines. And guess what happened? Yeah, I was stuck administering the machines. So, I installed Linux on one of them, and I installed Homebrew on the other. And we, we made out very well with that.

So I've got a little bit of homebrew experience and a little bit of Mac experience, but, you know, rather than us talking about what we know and don't know about the project, let's bring, let's bring the guys on. So we have John Britton and Mike McQuaid. Let me see if I have this right. John is the business guy.

And Mike is the homebrew guy. Is that, is that sort of the way the land lays here? 

Mike: Yeah, I don't know if John likes it put that way, but I'm fine with that description.

John: Yeah. I mean, I definitely wear more of the business hat, but I'm also a software engineer. So, you know, being called a business guy is a little bit rough right now.

Jonathan:  It looks like you're wearing the Tron hat. Yeah, I like it. Okay. So first off, how did, how did we do about, about homebrew? Let's start there and then we'll get into this kind of the, the, the business thing that's going on, but I want to know first, let our folks know. And so obviously this is probably a question mostly for Mike.

What, why, why would somebody use homebrew? What's the point?

Mike: So my I guess description for non tech friends and family is generally homebrew is a app store for open source software, essentially. And if they want to get deeper on that, you can go down the line, the fact that it's mainly both the software installed by Homebrew and Homebrew itself are primarily operated through the terminal.

So yeah, basically that's, that's the starting point of why you care about homebrew.

Jonathan: Yeah. And it's, it's all, is it all open source? Like, so I, I'm pretty sure that homebrew itself, the entire thing is open source, but all of the software that you go out and grab now, how much of it do you build from source at install?

It almost seems like that's one of the things that you at least can do.

Mike: Yeah, so that's a differentiation between kind of two parts of homebrew, like the original and some stuff that's come later. So originally homebrew was, everything was built from source on the user's machine. So I guess you would call it like a build from source package manager.

Yeah,

and over time homebrew decided that we were going to take more of that open source software that was built from source and build it ourselves. And then now we build everything ourselves. So most users most of the time are going to be given a pre compiled binary package, what we like to call a bottle because everything in homebrew has like a beer metaphor running through it.

Right. But then over time there was a project that it started off as its own separate project, but it's been brought into homebrew proper now called casks. So we have things called formula, which are used to install things from source, which are open source software. And then we have casks, which are used to install Software that is a binary that we get from somewhere else.

So a classic example of a formula might be something like W get or some other command line tool you're used to interacting with or my SQL or database or whatever. And then a classic example of a cost might be something like. One password or Google Chrome or zoom or something like that, where essentially the, the flow otherwise would be download from a browser, click, click, click, whatever.

Jonathan: How long, how long has homebrew been around? Like what, when was the the initiator of this idea? When did somebody first start writing code to make it happen?

Mike: So yeah, Homebrew turned 15 this year in May, if I remember quickly, it was created by a chap in London called Max Howell who was working for Last.

fm at the time. That may bring back memories for some of you that's, I'm sure they still exist, but you know, less widely used nowadays. They once were so yeah, he basically was exploring different package managers. And he could never find one that kind of quite, met his needs and I think he was nudged by someone in the pub one evening to go and well you know if you hate them all so much why don't you make your own one and he did and that's that's the future really and so yeah so that that was 2009 and then I got involved with homebrew Later on that year, like, I guess, September 2009 or so I, Max was a friend of a friend in London and I heard about it and I was also dabbling in package manager things and I sort of just started contributing and never really stopped, I guess.

So yeah, 15 years ago is a couple of,

John: I was just going to say a couple of months ago we had Max over and we did a live stream kind of going through the history of 15 years of homebrew as well.

Jonathan: Okay, cool. Is Max still, is Max still involved with the project?

Mike: No, he's doing his own things nowadays. Sure. He was involved for kind of, I guess, maybe five years at the beginning, and then he sort of handed it off to others.

Jonathan: Yeah, that, that's great. It's one of the, it's one of the problems we see with some open source projects. It's like even really popular ones where somebody starts it and it's like, well, I guess enough people like it that I'm stuck here for life. And so like genuinely good for him that he was able to get off the boat.

And the boat didn't crash.

John: Congratulations. Your open source project is successful. You have an unpaid job for the rest of your life.

Jonathan: Yes. Well, it's a, it's a huge problem. It really is. And you know, there's the, the, the classic XKCD comic. Like you have this, the whole, you know, massive software stack, all the building blocks, and you have this one little piece that holds everything else up.

And it's like, this is just maintained for nothing by, by one guy in Kansas. And the scary thing is there's multiple projects like that. Like you can talk about the network time protocol has been that way for the longest time. Even things people don't know about, but are super important, like the term info files.

And there's legitimately only like three people in the entire world that actually understand term info. I think I'm, I'm fully convinced of this, but you know, if, if those break, we're all in trouble. So. Let's, this seems like a good place to at least dabble in the concept. I, I've heard of something called workbrew, and it is apparently related to homebrew, and it is apparently also you guys.

What, and this is probably, if I understand the lay of the land correctly, this is a question for John. What is workbrew, and why, why are we trying to do it?

John: Yeah, so homebrew, is, you know, insanely popular, used on Mac OS. There's more than 30 million devices with Homebrew installed. And it's pretty much made to be a single player experience.

You sign on to your machine, you open up a terminal, you install some things, it's all managed kind of on your machine. And what we're doing with Workbrew is trying to make it so that It's more of a multiplayer experience. It's built for teams. It's built for companies so that you can have a kind of a shared set of developer environments across all your machines, a shared set of policies, a shared way to manage and deploy and install, get analytics and observability, know what's going on within your fleet and keep everything secure and compliant.

So what we're building now is really. focused on how teams are using Homebrew day to day and trying to solve their major problems. So I think you know, maybe Mike, you want to say a little bit more, but I'd say that's, that's kind of the starting point.

Jonathan: Yeah.

Mike: Yeah, no, I think that's

Jonathan: a good start.

Okay. Now is, is Workbrew open source as well?

John: Workbrew is not open source. We're built on top of Homebrew. I like to think about it as kind of complimentary. So at the foundation of work brew, we're using brew, the open source package manager. We don't have a private fork. We don't have our own custom version.

It's exactly the same as the open source project, but on top of it, we build a bunch of complimentary tools for deployment, analytics remote management, security and compliance those types of things. And our approach, I think this is actually probably the topic that's worth getting into in a podcast like this.

Sure. Is our approach to commercial software in an open source world. So as you know, homebrew is an MIT licensed open source project. We, BSD, BSD, apologies BSD licensed open source project. And we basically upstream all of our changes that are necessary. So anything that, that needs to be. Available inside of brew as the core kind of foundation we make available to everybody.

Then there's kind of a line and that line is pretty well defined and it's multiplayer. It's enterprise like kind of security and compliance features. It's managing remotely. It's all of those types of things that are on top of homebrew that are closed source. We don't make that available open source right now.

Jonathan: Yeah, and that makes sense. I think it's going to serve you well that you've, you've figured out that line and you have a a clear delineation and you make it clear upfront that like, this is the, this is the part that's always going to be open source. This is the way we're going to manage that. And then this is the part that we're going to build on top of it.

That's not. And at least I, as a potential user, I, I really appreciate that. And so do you, do you generally pull from the same like list of packages? So for one, I understand WorkBrew is going to be doing much the same thing. We're, we're installing extra packages on Mac. I think

John: something that's, that's useful to explain about Brew is kind of the two components.

One component is the CLI. So it's the actual package manager responsible for putting software onto your device. And then the second kind of component. Is the packages themselves, the library of, you know, as Mike was saying, formula and casks The homebrew project has two official kind of package repositories.

One's called core and one's called cask. In homebrew core, you'll see all of your built from source packages and in cask, you'll see all your binary distributions. A lot of that stuff may not be open source. Some of it may be open source to distribute as a binary from the upstream vendor, but ultimately you have those two components.

So when it comes to workbrew you're still using brew, the open source package manager, and you're still able to use the library of packages that are available for homebrew in core and in cask, but you can also create your own taps as they're called in homebrew speak that are repositories of your own internal packages distributed, you know, within your organization and you can kind of set rules and, and manage how that stuff is done at an organization level.

So that's kind of where the delineation is.

Jonathan: Yeah, that that makes a lot of sense. Yeah, David, you I'm sure you're chomping at the bit. We haven't let you got anything in yet.

David: So a couple of questions just from listening to you there. The first one, I noticed that you refer to brew and homebrew and workbrew.

So what are the, like is Brew core to both Homebrew and Work Brew, or is Brew and Homebrew synonymous? And just a shorthand. I'll

Mike: get this one. So essentially like we, we often use brew as a shorthand for either home brew or work brew because Brew is, that's the, the CLI. command that you type in to your terminal if you're Workbrew.

I guess to jump back a little bit because it might be interesting again, like the approach that we're taking and it might explain how things fit together. So essentially the flow for Workbrew is you run our installer. And our installer installs some workbrew stuff and it installs homebrew so homebrew is installed completely normally to the normal location but we just do some stuff where if you were to go and say that to the homebrew open source project they would be like why would you do that but because because we have a bunch of homebrew maintainers and People like me who have worked on homebrew for 15 years, like we can do some slightly more unconventional things with homebrew.

But on your system you still have a completely unpatched, normal, open source version of homebrew running on your system. But then we have essentially like a wrapper that we have on top of that. So when you run brew and you have workbrew installed in your system, you run workbrew, which then calls into homebrew.

But the essential behavior for end users is it looks exactly the same. So I guess John talked on this earlier, like me as a kind of long term lover of open source software, I kind of like this approach of kind of combining the two because it means that Both the open source software, Homebrew, gets better over time, but also we have the way, as John mentioned, like the realities of kind of making commercial software in an open source world where we can't give away everything for free or it wouldn't be a business, right?

So, yeah, I think you get the nice best of both worlds. And the other kind of fun, I guess, analogy I've used with this stuff is it's like My apologies to John, who's heard this particular analogy about 8, 000 times is it's like Lego, right? I don't know how much any of you are playing with Lego nowadays, like, but my, one of my kids is super into it.

And Lego now feels pretty different to what it used to be, where I remember like there was a lot more modification of models and stuff like that. Whereas now it's like a pretty hard line between like the super, customized, this Lego T Rex comes with a particular claw that is made only for this one piece and you can't use it for anything else really.

Or you just buy a bucket of a bucket of blocks and you assemble it and make it up yourself, right? Like essentially what we're doing with with workbrew is if, if you look through the pull requests that are open by me and other people in the last year or so, you can probably see the blocks of how you could go about building your own workbrew.

But I guess our value proposition is essentially like, well, we, we built it for you and we can support it for you and everything like that. So. You know, maybe you're better to buy it off us, but the open source project still has a lot more of these kind of like hooks and things that you can plug into that makes the open source project better and more useful for people as it goes along.

Jonathan: Yeah,

Mike: absolutely.

David: And the the next question that I had as I already established at the opening, I'm not great I don't have a lot of Mac experience other than some user and I've maybe I've used brew once or twice. But I do have Linux experience an open source experience. And so kind of relating brew to.

Package managers, I'm used to I have two questions and you can answer them. However you desire. The first one is, do you have package maintainers that are responsible for specific Applications within, you know, that homebrew would pull down. And then the second one is, you mentioned taps as something you could do inside your corporation as kind of like your own repository.

Are there. Publicly available taps that are like maintained by people not directly related to homebrew. I'm thinking of kind of like PPAs and Ubuntu.

Mike: Yep. So in terms of package maintainers, I guess that's an interesting thing with homebrew is that we don't have specific package maintainers. We have like somewhat officially unofficially People who might maintain individual packages, but the maintainers of homebrew are relatively few.

So we've got, I think, 30 something people right now and between them, they essentially maintain everything. But that doesn't mean that they do everything because homebrew was built with GitHub and collaboration in mind from the outside. I think Max on the, the video call that John mentioned earlier that we had to kind of talk about it, like one of his things from the outside.

I'm sure you won't mind me saying this if you didn't use this exact word was essentially to be lazy and be lazy. Okay, I don't want to maintain everything by myself, so how can I build this from the outset such that essentially the community maintains this and I don't? The other difference we have nowadays is we have very, very, very heavy amounts of automation to essentially detect changes and keep things up to date and things like that.

But I guess to specifically answer your question, though, we have a slightly different model where We don't have like hundreds of different people who each maintain one or two packages. We have a small number of people who maintain everything and like review community contributions to all of those things.

The next question about taps. Yeah, we have essentially the tap model is very similar to a PPA model or something like that where any arbitrary person on the internet can just decide to set up a a tap and then by default the easiest flow is having them on github but really you can put them anywhere where you can have a git repository.

I mean technically they're just a folder on a disk so any way that you can get a folder onto a disk and keep it relatively in sync you can make that a tap and they behave much in the same way regardless of whether they're being maintained by homebrew ourselves or whether they're being maintained by the community.

It's more just like we set a higher standard for like both. The licenses and stuff like that and styling and, you know, making sure our best practices are followed that the community don't have to do, and may decide they don't want to do, may decide they can't be bothered to do and that's basically how that kind of ecosystem fits in.

David: So, one follow up question. How many packages is everything?

Mike: Right now, I think it's about 20, 000. Oh wow. Between all of the formula and all of the clasks, so 20, 000 official ones. So if you go wider onto the, all of the third party taps and stuff as well there is probably considerably more than that but basically at least 20, 000 or so.

That's, that's,

David: that's astounding. Yes. Especially for a small team as you have maintaining it. And you've mentioned CAS several times, which I understand because you've explained that and you talked about formulas, but I've heard references to bottles, what are bottles and how do they relate?

Mike: So a bottle is basically like the original, as I mentioned way home we worked was it's was a build from source package manager.

So the formula, I guess it fits more obviously in the metaphor and the original stage in a formula. If you imagine a formula for a beer, it might say, you know, I want Whatever. I don't make beer like some sort of liquid and some sort of not liquid and mix them together and you get a, some sort of beer.

But so essentially a formula is a series of build instructions for like how you take an upstream source. So like say something like, w get the tar ball containing the source code for Wget, how you would go and run various instructions on your machine and produce a binary at the end. So what we do nowadays in Homebrew is that formula for most of the people most of the time is only essentially used for building a binary package on our servers.

So when that formula is modified on GitHub, then we will run through those instructions. We will build a new bottle, which is what we call the turbo that contains the binary package. And then we then upload that to, we use like GitHub packages to store our all our binary software basically. And then when a user types brew install on their machine, instead of doing through all those steps or essentially just downloads that binary package, that bottle, and it will pour the bottle extracting the tarball into the place on disk.

And then a user can have that up and running. And for, you know, for, for smaller things, the time difference is minimal for larger items. If you have a relatively normal slash fast internet connection, you can do that. you're talking about the difference between, you know, less than a minute versus, you know, even on high end hardware, like four or five, six hours to compile some of the really big meaty stuff.

So it can be a huge time saver for certain people and users. And it's also a lot less hour prone.

Jonathan: Somebody had a lot of fun coming up with that extended metaphor and figuring out all the ways that it fit. Well, I

Mike: came up with that. So if you want to blame anyone for that particular strange metaphor, that's me.

And then most of the original stuff was Max.

David: You can definitely tell that this was developed on a napkin in a pub.

Speaker 5: I think we're looking

David: around the room creating parts of the infrastructure.

Mike: Yeah, well, the first commit ever to homebrew is interesting. It's something I actually, I did a bit of at GitHub when I worked there as well, and I recommend it for people when they're doing projects is this idea of like readme driven development.

I don't know if you've heard of that before, but the idea being before you start a project, essentially start by writing the documentation of what you think. it should look like and how it should work. So thinking from the outside in. So that's how Homebrew originally worked. And if you look at the first commit to Homebrew, the first commit is actually a readme of how Homebrew works, despite the fact that there's no code at this point.

And yeah, and the last question in the readme is, was Homebrew conceived while under the influence of alcohol? And the answer is yes.

David: Both Unix and Linux were conceived under the influence of various substances.

It's true.

Jonathan: All right, I'm going to jump in and I want to ask John a couple of questions about Workbrew in particular, and Let's see. So I'm, I'm assuming that the way we could set this up is a business would, would say, look, these are the packages that we want to allow people to install on their machines that we're, we're in charge of, and then we have this whole other block of packages that we, we don't want to allow.

Like, that's the sort of tooling that, that you guys give with WorkBrew, right?

John: To some extent, I think like I would actually preface it by saying that for us, the most important thing is a developer experience. Brew is kind of a tool, a tool belt for software engineers. They go to brew and they get all the things they need to do their jobs.

The reality of the situation is that companies, especially in highly regulated industries, you know, we talked to a lot of banks, a lot of you know, FinTech type companies, governments. Insurance companies, healthcare. The rules of the road there are just, you have to do certain things a certain way. And so rather than think about it as a way to limit folks and what they can do, it's more a way to enable developers to continue to use the tools that they know and love at

Speaker 5: work.

John: So we think about it as without Workbrew, the people in those companies would be told, no, sorry, you can't use brew. It doesn't meet our security and compliance requirements. And so with Workbrew, what we do is we make it so that. The IT folks, the security folks are able to feel comfortable with the risk profile of giving end users, developers, the ability to go out and install 20, 000 different open source packages.

And in some cases, you know, especially the financials that I talked to, they have some requirements around things like data protection, data loss protection. So they don't want to allow anything that opens up tunnels in the network. So particular VPN packages, wire guard. You know, Ngrok, stuff like that, where You know, they're honestly like useful tools that are not necessarily nefarious, but because of the risk profile of those businesses, they just can't allow it.

And so that's really where the kind of security and compliance type of, you know, restrictions come in and work brew. And with every customer that we work with, we talked to them about, you know, the developer experience and how they can maintain a positive developer experience. And instead of, you know, You know, using hard and fast rules, setting policies that they can monitor and see if, if something is out of policy.

So every every user that we have, generally the way that they come on board is they do a complete audit of every package that's installed on every machine. Yeah, homebrew. This is a huge amount of information for them. They had no visibility previously as to, you know, let's say they have 500 engineers, 1000 engineers, what packages were being used, what their, you know, potential surface area for attacks was, whether it's supply chain attacks or, you know, other kinds of data loss or things like that.

So they can do an audit and they can see everything that's happening. And then once they have that information, you know, They can take steps to provide alternatives rather than just say, Hey, this is turned off, you have no access. We give them a way to say, Hey, the preferred tooling for this job is X.

And we really are excited about the features around kind of collaborative developer environments for software engineers. So the idea is that rather than each person in kind of a single player mode managing their entire kind of development stack themselves, if one person finds a problem, whether it's a security issue, a productivity thing where they can move faster, When they make that change, they're able to share it with their entire team, you know, seamlessly.

So that's, that's some of the ways that we think about, you know, The same thing that you were saying, but really from a first principles, you know, mindset, why are we doing this?

Jonathan: Sure, sure. Does either work brew or and or home brew provide like automatic updates? Or do you have to go in and say, all right, all the packages I've installed, go check for new updates and install them.

John: I mean, the short answer to that is kind of it depends what you want. This is another one of kind of the principles that we're trying to follow, which is one size doesn't fit all. We have, you know, these fast moving tech companies that really want to embrace the cutting edge and they always want to have the latest version of everything all the time.

And on the other hand, we have, again, these highly regulated industries where they say, I know that a new release came out, but we cannot deploy that new release into production until a human has reviewed it. Yeah. They've created a signature, we've entered an entry in our audit log, and we've allowed it to enter the production environment, right?

And so these are two polar opposites. So, our principle here is like, one size does not fit all. We want to give people the ability to kind of choose how this should work. And Mike can talk about, you know, Homebrew's auto updating. Facilities.

Jonathan: Yeah. I'm curious about that too. Mike, I'll let you take it for a minute.

And, and what, what's the solution there with, with homebrew itself?

Mike: Yeah. So homebrew by default will basically. Almost every time you run a significant command, it will auto update itself and it will try to ensure that it always results in a consistent state, which involves, it will do things like auto update, auto upgrade, like reverse dependencies and all this type of stuff.

So I, I guess in general, like Homebrew is a developer tool, like my, thinking is if you ever are having to have in tools a thing where you say, Oh, if you run this command, make sure you run this command afterwards, then that's generally not very good UI, right? Right. So my, my goal is over time that Homebrew essentially, you can just get away with installing software and everything else that you might need to do running updates, doing cleanups, upgrading things, getting rid of things you don't need anymore, auto removing things you don't need anymore, like all of that stuff is done.

fairly seamlessly and automatically. And I guess another note related to a couple of things that came up before it, I guess we haven't mentioned explicitly in the school before, but I would be Sad if I were not to mention the fact that Homebrew also runs on Linux, which is, it may seem slightly strange as to why one would ever want to do such a thing.

But one of the cases we've seen on Linux is I guess what John mentioned earlier, where one of the things with Homebrew, because it's a rolling release package manager, which essentially means when Homebrew can get the latest update of a thing and it works and it doesn't break Homebrew stuff, then Homebrew will upgrade to a newer version.

We've seen people using You know, a more stable like base layer OS, Debian, Ubuntu, whatever, and then they might install. homebrew somewhere on their system on Linux and then they can get access to kind of maybe the bleeding edge for certain developer tools. Like if you have, I don't know, like a classic, like a CLI I love is RIP grep.

It's a RG is the command and it basically just does really, really, really fast recursive grepping through folders and stuff like that. It's what VS code uses for file finding text and files. So a tool like that, for me, it's like, I, If I want a Linux machine, I get frustrated if I have to wait, you know, like months for someone to get me the newest shiny version of RIPGrep.

And also the blast radius, if it, you know, If it doesn't work, then it doesn't really impact anything else in my system. Right. So then you, you can get this nice combination. And in a funny way, that's sort of how Homebrew works on macOS as well. In the, the, the reason why I'm drawn to macOS is because when I was using Linux I'm too much of a tinkerer and I would just continually break my system by being like, Oh, if I, if I increase, I'm showing my age a little bit here.

If I change X. org settings to do this, then maybe The refresh rate will look slightly nicer. Oh no, I'm stuck in a terminal for 24 hours, all this type of stuff. Whereas the, for me in the macOS world, like essentially apple of like nailed down that that trunk of my bonnet, as we'd say over here to my car.

So I can't get inside there. And that's for people like me, that's better for other people. That's worse, but you can sort of have a more Mac like. feeling with your package manager if you run homebrew Linux in that way.

Jonathan: Yeah. So I was going to, I was going to ask about, I have a little note here on my notes to ask about running it on Linux.

So this, there's a question that obviously follows up. Can we run workbrew on Linux? Does that make any sense?

John: Yes, but I would say not yet. This is something that we've talked about. I've had definite, definite interest from folks we've been talking to just have consistency across all platforms, the ability to see what's happening everywhere and be able to remotely manage them.

We don't have folks using Workbrew on Linux today, but I expect we will in the near future.

Mike: Okay. And now we have internal prototypes, basically, right? We have not yet released for what, but I mean, essentially homebrew works similarly enough on both cases and our internal prototypes are, it's the type of thing where it's the classic engineer thing of if I was earlier in my career, I would say, Oh yeah.

We could have a Linux version out in a couple of days because it all compiles, right? Like that's, that's the easy bit. It compiles, what could go wrong? Exactly. I, I've learned enough over the years that I'm like, well, you know, there's, there's probably more, the iceberg here is probably. Perhaps a little deeper than I might want it to be so

Jonathan: yeah in the past 24 hours.

I've pushed code that compiles I was that developer today within the past 24 hours Now work workbrew is available though like not not the Linux side of it yet But on on Mac if somebody really if like if this is the tool that meets their needs work workbrew is out there They can get it

John: Today, the way to get Workbrew is to come to our website, workbrew.

com get on a call with me and I'll show you around. We expect very soon probably in a matter of weeks, to have it publicly available for folks to just get on and try. But right now it involves kind of a conversation with us to see if it's a good fit for you. And really the reason for that is that we're We're looking for design partners.

We're looking for companies. We're looking for for teams that See the same set of problems that we see With using brew in a team environment and who really want to give feedback and help us build this tool together but we have it in production with a number of different companies. We use it ourselves every single day So it is there and it's up and running but it's not entirely self service as of this moment,

Jonathan: right?

What's the what's the uptake look like? Have you had quite a few companies that are a good fit that have come on? You

John: We had a really interesting situation maybe a couple of weeks ago. Mike was interviewed on the next web and there was an article that led to quite a lot of interest. Over the last few weeks, I've basically been in nonstop conversations with lots and lots of name brand companies that you've probably heard of, but I can't talk about.

But again, many of them are in these like kind of regulated spaces where it's, we're a finance company, we're a healthcare company, we're insurance, we're government you know, some kinds of, you know, different. Use cases for exactly the same thing. It's all different industries, but they're all saying, we'd love to use this, but our requirements are such that the open source thing just doesn't, won't fly here.

And really there's kind of like three stories that we see at companies. The first story is do nothing. They just let brew kind of be the wild west. Every developer who wants to use it just installs it on their machine and IT and security look the other way. The second kind of big category of folks is, you know, this informed trust model where You start at the company, there's a readme that says part of setting up your dev environment is installing brew, installing these 27 packages, here's a guide, probably the guide's out of date and it doesn't work when you first start, and then if something's wrong, there's that one expert who's done a lot of stuff with brew that you go and ask for help and that's really, really common, and then kind of the least common, but pretty popular case, especially among very large companies, is that they have some kind of internal tooling built around this already.

So they'll build custom scripts to integrate with their MDM tools so they can manage a fleet wide deployment of brew. They'll build scripts to do things like inventorying what, what packages are installed on their devices, reporting version numbers, and cross referencing that with vulnerabilities databases.

They'll do things like add self service scripts to their MDM tools so that End users who don't have admin privileges on their devices are able to install brew packages. But the downside to that is that for every single package in brew that your company uses, you have to have a staff member who's like maintaining that in your MDM tool, keeping it up to date, keeping it in sync.

It's just like unbelievable the amount of hurdles that people go through to make this work. And so yeah, the interest has been phenomenal. People are very interested and kind of those three categories of folks, they all hear from us and they say, wow. Why, why has this taken so long? Why hasn't this been here before?

Like, it's so obvious. So yeah.

Mike: Building as fast as I can, John.

Jonathan: And I assume part of the, part of the sell is, rather than you have to have this one guy at your business that understands brew, you've got the actual brew guys that understand brew. And you pay us enough money, you can call us and we'll fix things for you.

John: Yeah, that's definitely part of it. I mean, Mike is very generous with his time with our customers in terms of getting them up to speed on what needs to happen with brew.

So, yeah.

Jonathan: I mean, that's sort of a win win for everybody though. Right? Like I know how to do this very specific thing. You need somebody to do this very specific thing. You give me money and I do the thing like that's.

John: Well, the really beautiful part of this whole thing is it's not just one company that needs this.

Jonathan: Right.

John: They all, they all need the same thing and doing it once and making it, you know, reusable and, and, and packaged in a way that every single company that has this problem can adopt a standardized tool. We're basically saving an entire team's worth of effort at every one of these companies, right? And so, the individual kind of ROI calculation that each of these companies has to do is incredibly obvious that it's the right decision for them.

You know, rather than paying a team, you know, I could, I could list off maybe five or six of these companies that everybody knows and uses their products every single day, and they all have teams of people that are managing this problem. And in every single one of those cases, They would get a better solution from us.

It'd be more purpose built. It'd be more highly integrated with Homebrew. It'd be less maintenance costs for them. Less kind of distraction for their teams to have to manage it. It's just a very, very easy decision for them to make the buy versus build decision because, you know, the lack of expertise, the ongoing maintenance costs, what happens when a new version of Brew is released, what happens when a new version of macOS is released.

You have to, you know, You know, if something doesn't work, when one of those events happens, every single engineer in your company is stuck.

Speaker 5: You

John: know, that's a high cost.

Jonathan: Yeah.

John: So, you know, we make sure that never happens.

Jonathan: Just, just make sure that you, you, you don't pull a CrowdStrike and

John: Oh, absolutely.

Mike: I would be remiss if I said that, that, that hasn't been a thing that has been talked about recently when we've been talking about, deployment strategies and things like that of, yeah, there's there's ways to do this and ways not to do this and let's not do it the way that maybe doesn't always go so well.

Yes.

Jonathan: Yes. Have you gotten to the point to where particularly based out of these conversations with businesses, you've started adding things that you hadn't thought of to either work brew or home brew?

John: Oh, absolutely. That's kind of the biggest thing that we're doing right now is just listening to these customers about the problems they face and trying to build the most general solution.

I mean, Mike likes to say this thing about the baby. Do you want to give your kind of baby analogy about how this works?

Mike: So my, it's funny, at Homebrew, I'm probably the closest thing Homebrew's had to like a product manager, at least since Max left. Yeah, I guess. Working at GitHub for 10 years, I saw some product management done very, very well, and occasionally some product management done less than perfectly.

And something I feel like I learned from this stuff over the years, particularly when your audience is developers, is the line I like to use is users are, or customers, or developers, or whatever you want to pick. Or like babies in that they can cry and tell you that there is a problem, but they cannot tell you what the solution is to the problem.

The tricky thing is, developers compared to actual babies even if those babies may one day grow up to be developers developers tend to tell you, go jump straight from, I have problem to, and if you tasked me with how I would build this solution, how would I build the solution? And they come to you saying, what I need is, the solution that I would have been tasked with building.

And often they don't necessarily have the context that you do. They don't maybe think about like, what are the average users like? So a classic thing that this would come up in Homebrew quite often and the nice thing in Homebrew is you can just decide to do these things because it's not as higher stakes as certainly GitHub was and Workbrew is increasingly becoming is.

On homebrew, someone might say, Hey, I've, I've added a new option that I want to opt into for this particular behavior. And then I read it and I think about it for sometimes not very long. And I'm like, why would you ever want that option turned off? It's essentially like, I, I've added a flag. So when you run this homebrew command if I have my face puncher plugged into my USB port, it doesn't punch me in the face.

So I sat homebrew underscore, no punch me in the face, please. Right, and I'm like, well, maybe punching you in the face could be opt in. You know, like, let's flip the logic around. Or maybe let's just make homebrew punch free software. Like, maybe we can skip this flag altogether. So, to me, like, that's the type of stuff that comes up.

And again, I don't blame any, you know, Person who makes a PR like that, because they're, they're trying to be a good dev and be like, okay, I need to, I don't, I'm not sure that anyone except me cares about this. I want to narrow the impact radius here, but I can look and be like, well, actually everyone cares about this.

Jonathan: Yeah, it's, I don't want to break anybody's workflow. Right. I don't want to. Stop overheating when you hold the space bar down for everybody. That might be important to somebody's workflow. And, and that I did the, the, the baby analogy. I like that, David, I'm sure you get this too. Like a customer will come to us and say, I need this.

And then they'll, they'll tell you this most off the wall thing. Like, yeah, I need a new server. That's got a GPU in it. You need a one now. And then you, okay. What's the problem that you're having? Well, we'd like to be able to use. We'd like to be able to do this. And it's like, Oh, we need to get you an account at, you know, chat GPT.

We don't need to build a server. It's got a GPU in it. I'm sure you get that too, David.

David: Reverse it. You kind of have to, you're given instead of. The baby crying, they come to you with a solution and then you have to reverse engineer the solution to figure out what the original cry was. So you can give them a better solution to

John: your original question, though, about like, what have we built?

That's come out of, you know, customer conversations. We've had a number of, you know, customers come to us and are kind of very You know, common customer profile is ahead of I. T. Somebody who's responsible for managing you know, their MDM at the company, like the jam for Kanji or one of those type of tools.

And they'll come to us and say, Hey, one of my jobs is software patching, and I need a way to know when something has a vulnerability. And how I can really quickly fix that vulnerability and know that it's been fixed across my entire fleet of thousands of devices. And so we built a vulnerabilities dashboard that effectively takes a look at every single package installed across your entire fleet, catalogs all the version numbers, knowing exactly which version is installed on each device, and cross references that with a bunch of different data sources where we have information about all known vulnerabilities in those packages.

And we present this as a nice simple report for this IT manager to say, Hey, package X has a vulnerability at this version and it impacts 205 devices at your company. Click this button to apply a patch that fixes that on every single device. And after about 15 minutes, you can see 95 percent compliance, all of those have been patched, and a few of the devices that were turned off, you know which devices they were, so you can send a Slack message or give somebody a call to make sure they boot up their device and upgrade that package so that the vulnerability is addressed.

And that came directly out of, you know, customer. Customer requests.

Jonathan: Yeah, so you guys kind of provide a software bill of materials for across the whole organization Yeah, yeah, absolutely super interesting Okay. Now with with brew itself. We've talked a lot about command line applications Do we do do we do GUI applications?

Can we install, you know more complicated or less complicated but good GUI based applications Can we do real crazy things? Can we install entire bright light? Can we install Firefox with brew? Is that a thing that works?

Mike: Yep, and not only is it a thing that works so that this is essentially the way I Interact with homebrew primarily nowadays.

So one of the things we've built on top of homebrew was this thing called brew bundle Which essentially the the bundle part of the name relates to if homebrew is written in Ruby and there's a tool called bundle or bundler I guess is the full name that consumes gem files which are a list of ruby gems essentially like third party ruby modules and then builds them all together so you kind of have all these in your app.

So homebrew there's a part of homebrew called brew bundle which does the same thing with brew files where you can basically have a bunch of software In there. And you can specify, okay, I want these formulas. I want these casks. I want these things from the app store, the Mac app store. I want these VS code extensions.

And, you know, probably more to come in future on basically like the way that allows you to use homebrew is instead of. Saying, okay, install this, install that, uninstall this, uninstall that. Instead, you can have a list of essentially, here's everything I want installed on my machine. And, anything that's missing, I want you to install it.

Anything that's out of date, I want you to upgrade it. Any, you know, background services that I specify, I want you to run them. And you can also tell it to do a cleanup, which means any software that is not on that list, I want you to uninstall it from my machine. Which is probably mostly useful to people like me, who accumulate huge amounts of cruft testing various homebrew packages.

But the nice thing with that brewfile is then, you can, Like my most popular not homebrew open source project is a thing called strap I built for primarily originally for github's internal use, but it can be used by anyone And basically what that lets you do is say, okay when I first set up my machine the first thing I want to do is pull down this list from a github repo and I So as long as you're kind of relatively diligent about like dumping software to that list and then committing that to that repo, then you can get essentially a nice single file description of here's everything on my machine.

And if you're one of those people who likes dot files, Like having all your configuration files, like there. That's the repo that I put that in. And again, that tool pulls down your files repo. And essentially my goal with that repo is I should get my machine 90 95 percent set up by just the contents of that repo being pulled down and all these scripts run and stuff like that.

And nowadays I even have all sorts of mad things that Extract secrets from one password and write them to the right locations on disk and and all this type of good stuff And but yeah, but as you can tell this workflow is very heavily github centric right now. So if you are interested in a non GitHub centric version, then again, stay tuned to what brew is up to in the future.

Jonathan: Yeah, interesting. Now does brew, does brew help with doing like program installs without using brew? So like on, on Mac, the the, the, the normal way to install software is like you, you get your package, you double click it and it gives you this nice window with here's the application and here's your applications and you just click and drag can, can we do something real fancy, like build a package in brew and then Spit out that zip that then someone can install without using brew.

Is it, is that in scope?

Mike: Exactly what casks are basically most casks. That's what they do. So if you, the, the Google Chrome cask, effectively what that does is downloads the Google Chrome. So in comparison to maybe a Linux package manager, a Google Chrome cask, that's not some special version of Google Chrome that's made by the homebrew team that just downloads the installer from the homebrew team.

Apples, sorry, apple, apple, not making a crew installs the doubt from Google's website. And effectively that kind of drag and drop or click through and install or next, next, next, accept, license, etc. Like all of those steps are essentially automated inside the cask. So instead I can type brew install google chrome and then at the end I get the exact same result as if I'd gone and walked through those steps manually of the google chrome installer.

And the nice thing about that is it essentially provides a higher level API on So there's about 10, 000 casks, as I mentioned before. That's essentially 10, 000 pieces of software where the API for how to install it is, well, do I drag this thing? Do I click the thing? Do I download it from here? Do I like have to run a terminal command?

No, it's you run the same terminal command for essentially any of those. piece of software and they are all installed the same way. And to me, that's the most powerful thing about both casks being in homebrew, but homebrew itself is essentially you have this high level API for this stuff. And when I was talking about my brew file before my brew file has a bunch of casks in it.

So I'm not just installing my developer command line tools that way. I'm installing slack that way. I'm installing zoom that way. I'm installing like all my like Safari extensions that way. So essentially pretty much all the software on my machine. It's being, in fact, probably literally all the software on my machine that is not provided by Apple is being installed through Humbroo in some way.

John: Yeah. And on the software that's provided by Apple via the Mac App Store. Brew bundle also has an integration with a tool called MAS, which is the Mac app store command line. And so you can actually add to your brew file just like you would add brew in the name of a formula or cask in the name of the cask.

You can add MAS and the identifier of an app in the Apple app store, and it will automate the process of opening up the Apple app store and requesting to install the brew bundle. the program from Apple onto your device as well. So literally everything can be put into this brew file and automated.

Mike: Yeah, that's great.

If there's show notes or people watching along, in some ways it's easier to kind of see rather than do it. So if you Google for Mike McQuaid which is My name, you may struggle with the spelling of that, but I'm sure you'll get there in the end. And then brew file B E R B R E W file. Then you will get the top hit to like my brew file in my public dot files repo.

And then you can see like what that looks like. And please don't critique my particular. Choices of software because don't don't that very near and dear to me. Do it out of me.

Jonathan: Exactly. Now can we, can we go the opposite direction? So let's say, and I've, I've, I have this question because I've had to work through this before.

It's been years ago, but for a while I was developing an applique, a cross platform GUI based application. And one of the things that was a challenge was building that drag and drop installer. So, you know, if you didn't want to tell, so you could tell people, okay, go install brew and then install my application.

But if you don't want to do that, you want to give people that zipped up installer where you just, you drag and drop it and that's it. And it seems to me that there could be a opportunity here to To have a script inside of brew where you run the build and it gives you the installer that then you can go out and Give to people and has anybody done that?

Is that something that that brew can do? I know that's kind of a weird That's it's a weird idea, but I it would have been useful to me back then

Mike: I've seen people do such things in the past. I think what makes it tricky is, well, so I guess the two sides of homebrew, right? So the, the casks, for example, that essentially already exists.

If you have a cask for, as I mentioned, Google Chrome, that's means that that's already been provided by the upstream software, but then with homebrews formulas for, you know, say you wanted to install some sort of open software. Open source software that way. The tricky thing is because Homebrew has its own little special snowflake ecosystem where everything works just such how it does.

Essentially, In Homebrew, everything wants to pull everything else from Homebrew and be updated by Homebrew and be in the location of Homebrew. So that doesn't make it impossible. I mean it, you know, technically it would be possible to do such things, but it makes it trickier. My best actual experience in the past, to give a shout out to another open source project, is this a cross platform build tool called CMake, you may well have heard of.

What's less known is it comes with a thing called CPAK, which is C P A C K. So that basically lets you do cross platform packaging like this. At previous jobs I've used it for essentially generating, you know, like when I used to work on Qt applications for generating a nice click, clicky clicky windows installer or a RPM or deb for you know, Debian or Red Hat based distributions or a Mac OS kind of drag and drop style or like traditional clicky clicky installer.

Like you can essentially spit all of those out from the same project. And that also provides some third party tooling, some of which I may have contributed to myself, that aids in doing things like pulling all the libraries from Homebrew and putting them in the right place and all this type of stuff.

So it's kind of out of scope of the Homebrew project itself, but like, you can. You know, if you, if you look a little bit funny at the problem and take tools like CPAC, then you can definitely rely on homebrew a little bit to solve this problem

Jonathan: a little bit easier. Yeah, sure. Okay. So is there, and it seems like there used to be is it Mac ports is also sort of in the same space that there are some other projects that sort of solve some of these same problems, right?

Yeah.

Mike: Yep. So Mac ports is one think is another. And I guess, yeah, nowadays people are using Nix in some cases as well.

Jonathan: Oh yeah. Is there any cross pollination? Like did some of the same, maybe same people doing the, the, the, the package management or yeah,

Mike: I don't know. So I wouldn't say there might be.

We definitely. We talk to each other. So, and sometimes not, well, I mean, when I say talk, I mean, I don't mean it in the silly way that, you know, normal humans would actually talk to each other like we're doing right now. We, we, we type things at each other on the internet and there is collaboration in some ways between the projects.

Some of it is explicit, like where we might go and we have kind of shared channels with some of these folks. where we might kind of figure out problems. And then some of it is the, in the nicest open source spirit of the world, us, like, various projects stealing patches off each other where, you know, maybe there's some new macOS version or compiler version or whatever it may be, And someone, one of the package managers writes a patch and the other package managers need the same patch so then they can take it from each other.

So we've all, again, there's a nice collaboration where we've all done that from each other. And also sometimes for inspiration where if a particular package is not working on homebrew as well as it should, or we get a complaint and someone says, Hey, this works fine on Mac ports or Nix or whatever, we might go and look and see how they do it.

And again, I'm sure. The same thing is happening in reverse and same with the with the There's probably just as much if not more actually with the Linux package managers as well and the BSDs as well because the BSDs use Clang as their compiler, which is the same as what we use So yeah, so there's basically, it's nice.

It's kind of classic open source Collaboration and action really in that like all these projects because we're all open source We can all share information and resources and help each other out with stuff

Jonathan: Yeah, I have anybody interested in workbrew asked about any of those other other tools. You know, I could, I could imagine someone say workbrew sounds great, but we want to be able to use Nix as the back end.

John: Haven't, haven't heard that one yet. But we have had some folks that are, you know, coming with like cross platform requests. So they say, for example, we want to have consistency across all three major platforms, Windows, Mac, Windows, Mac, and Linux. And it's been particularly interesting with regards to non developers.

So there are definitely companies where they have kind of a wide range of employees and some of those employees are using brew today and they understand it and they rely on it, but they also don't want to have a different system for, for example, our customer service team or for their data engineers or for data science or, you know, folks who depend on code and packages, but may not be as comfortable using the terminal and installing things.

And so we've talked to them about. How can we provide a singular way to provide a developer environment across all three of those platforms? So that's been probably the most similar kind of questioning that we've had from people. But not directly to say, Hey, I have like five different kinds of package managers.

How do I use them all together? More it's like, we use this one thing. It's really cool. How can we make it work for everyone?

David: So I assume on Windows, since Brew works on Linux, you could run Brew under WSL today. But it's the Windows specific stuff that probably needs some

John: Yeah, you can run, you can run Brew under WSL today.

That's how most of the people that I talk to who have interest in it are doing it. So I've talked to potential customers who say you know, we have this 10, 20 people over in this department who are using WSL on windows because X reason, can we get those mapped into work brew as well? I haven't had the same question about, Hey, can you run this natively on windows?

That almost never has come up. But there's a, there are other Rather than saying like, hey, we have this MDM tool, because really the people that we talk to a lot are the ones who are, you know, the IT managers who are responsible for getting the fleet out into the hands of the, of the company's employees and making sure they have the tools they need to do their job.

And so what they're saying is, hey, my MDM tool, whether it's Microsoft Intune, Jamf, Kanji, whatever, has a couple dozen applications in its built in package manager. In Kanji they call them auto apps, in Jamf I think they call them catalogs, but the idea is that, you know, Google Chrome, Zoom, Slack, all of those come as like default packages that the MDM provider keeps up to date.

But they say, well, we have this, you know, this couple dozen packages that are not managed by them, we have to manage ourselves. But Brew manages them, we can use Brew instead. And so they want to standardize on a, on one, one tool for all of this. That

David: makes a lot of sense. So another question that I had was just about the interface.

So you talked to, you mentioned the cross system management and like you talked about how you could, See your systems updating with work brew and identify the ones is that a web portal? Is that something built into the work brew command line?

John: Yeah, the overall architecture of what we ship is Three pieces on top of brew.

So it's brew the open source project Plus we ship an installer PKG file Which is a Mac PKG that basically enables zero touch deployment of brew it makes it so that if you have a brand new Mac You business manager, the first time that you turn it on brew is installed and everything is secured. If you have existing devices with brew installed and maybe dozens or hundreds of packages installed on those devices, you can run the PKG file locally or you can run it via your MDM tool and brew on that device will effectively be upgraded to work brew so that it will have that kind of connection back to the system on the kind of Administrative interface, there's what we call the console, which is a web portal that gives you a high level overview of every device in your system or in your fleet, and it gives you a high level overview of every package.

So you could say, for example, which devices are open is open SSL installed on. What versions are installed? Are there any known CVEs against it? And then run a patch to say, upgrade it to the latest version because there was a known vulnerability we want patched. So that's kind of how the interaction works.

On the device, there's one more thing that like, kind of goes to what I was mentioning earlier. One size does not fit all. So, on the device, we give companies the opportunity to choose different permission models. We call them Restricted, Managed, and Guided. So Restricted is the most controlled. This is kind of useful for individuals who don't know what the command line is, may not have any interest in brew, may not even know what brew is, and you want to manage all their installed software in the same way as every other device.

So you can install WorkPro on their device and essentially provide it in a restricted manner where the end user has no access to the Bruce CLI. It's only managed remotely. So again, great for like a customer service team or maybe data analysts, people who might not be comfortable with the CLI. Then there's managed mode, which is kind of the, Big most popular thing that we're seeing among companies with developers where we install brew on their device for them via the PKG via their MDM tool and give the end user access to brew via the brew secure CLI, the wrapper that we have around brew for the end user.

It behaves. It's just like normal brew so you can do brew install, brew uninstall, upgrade, tap, you know, pin, whatever they want to do, any normal command, and those commands are parsed and kind of made subject to policies or configuration options in brew so that, you know, we keep things secure and compliant.

In those cases, what's really interesting is the end user on the device doesn't necessarily have to have admin privileges. So one of the big kind of points that we hear from, especially the regulated companies, is we can't let people use brew because in order to use brew successfully, they need to be admins on their devices.

And for legal reasons, we're not allowed them, allowed to have them have admin rights on their devices. We just cannot do it. So we basically enable them to give their users the same brew experience that they know and love. without having to offer admin privileges on the device. And then the third kind of mode is more progressive companies that want to give their engineers full access.

It's essentially the same kind of guardrails around policies and how you can use Brew, but if they have admin privileges on the device, they're able to effectively escalate the privileges and go around these guardrails and say, even though it's out of policy, I'm going to do it anyway, so I'm not blocked.

And then the kind of management or the IT and security teams will get an alert to show them that. This device is out of policy or this package is installed in my fleet out of policy and then get up to date that way.

Jonathan: Yeah, so it sounds like you're not planning to bring brew itself to windows.

PowerShell. I was going to ask about that.

John: I think Mike is best suited to answer that. Never say never.

David: It just sounds like pain and suffering though. A follow up question on the whole dependency management. So, I have DevOps experience where you're, you know, developing webpages or web applications.

And so, you need to keep your dev system in sync with the same versions that you're running on your production systems. Do you have anybody using Brew to manage the software stack on production systems? Ah.

Mike: Right now, not really. It's essentially Homebrew, as you mentioned there, like the, the limitation you, you generally have in production is you want to have everything locked down to very, very specific versions that are consistent across your entire fleet.

But That's not the model in which Chromebrew operates by default. That is increasingly the model we're seeing people wanting Workbrew to operate in default. So we are building stuff in that direction. Again, sorry, I can't say too much there, but essentially like that, well, I guess it goes back to the, the babies we were talking about earlier, right?

Like essentially this is, this is a crying baby problem that we are aware exists even in development modes, but certainly the desire to have everything consistent between CI, dev, production that, that is a problem that exists today. There, there is not a great solution to, and there is a problem that we are working on right now.

I guess the Homebrew middle ground there is because Homebrew is a rolling release package manager for cert, it used to be Homebrew was just, you know, You get the latest version or you, you don't get a version, right? Like you have to just pick between. Now, more popular packages with kind of better support for kind of running older versions, say something like MySQL or Postgres or Node.

js, Ruby, whatever it may be, that still provide bug fixes, security releases, etc. for versions beyond the most recent one. You can install a package and you might say, you know, brew install nodejs at 18 or whatever, right, which gets you a like less than the current newest version but will continue to get you patch releases and security updates and stuff like that.

I guess a sort of balance I've seen with this stuff as well is that historically, The enterprise, the maybe individual developer model is let's just have the newest version of everything all the time and the enterprise model has been, let's pick a set of versions that work and then essentially only ever upgrade them if we absolutely have to.

But the problem with that flow is you often end up in a situation where, whoops, we probably should have upgraded this version a while ago and now a bunch of bad actors have got access to our product. either development machines or servers or whatever it may be because we decided to sit on this version indefinitely even when there were security updates that we were too scared to install.

So to me there's a, there's a happy middle ground to be found. Homebrew leans slightly more towards the like, you know, let's have the newest thing of everything all the time. But as I say in WorkBrewland we're building, essentially we already have some tooling there to essentially get that middle ground of like, okay well this package is actually vulnerable right now so I don't care if you're trying to sit on an older version because.

Some perceived view of stability like let's upgrade everyone. So at least they're not in a vulnerable version anymore.

Jonathan: Excellent. All right. Well, we, we have hit the the top of the hour, so I want to get into rap. And one of the, one of the things I want to ask you guys is, is there anything we missed? Is there anything we should have asked you about that you wanted to let folks know about that we didn't cover?

It's kind of challenging question because you've got to do some set math and think about all the things that we talked about, but if there's anything that comes to mind,

John: I mean, I guess there's one thing

Mike: that I might mention, which is, yeah, I think I mentioned like Linux before I'm developing environments and stuff like something where.

We've actually seen quite a lot of use of homebrew that might be worth playing around. For folks who are listening here is homebrew runs pretty well in, if you're using GitHub actions or, you know, GitLab runners or whatever it may be. That's a nice way because the packages are The same on Linux and Mac, and because the versions are in sync, that can sometimes be a nice way to have your development environment and your CI environment in sync, where you might have your developers using Macs locally, say, but then they might have a bunch of tests running on CI boxes, which are most of the time, for cheapness reasons, going to be running on Linux.

So if you do, you know, use a brew file, like I mentioned before, or even just run brew install. go or whatever it might be, then that means you can have that consistency between what you're doing locally on your Mac and what you're running in your CI environment. Yeah. And that can be kind of quite nice.

Yeah, absolutely.

John: I was just gonna say that you know, if this, any of this sounds interesting to you, Mike and I are both available you know, to talk to people. You can find us on our website, workbrew. com. There's a contact form that goes directly to my inbox. I'd be happy to chat with anybody there.

We're also active on, you know, GitHub and Twitter and things like that. We'll give our contact information for that as well.

Jonathan: Yeah, and we'll make sure and get that in the show notes for folks if they want if they want to reach out probably a question mostly for mike Although john, if you have any stories, you certainly can tell us what's the what's the most surprising thing?

Somebody's done with brew. What what does somebody? Message you or written about and you know, I didn't know you could do that with brew Or why would somebody want to do that with brew? Well, I, I'm

Mike: actually going to choose to misinterpret your question because I think you'll find it's slightly more funny.

The version that, so the thing that jumped into my head was almost like, what's the, what's the. What's the stupidest thing you've seen happen with, with homebrew? Stupid can be surprising. Yeah. So my favorite bug of all time actually is we might be able to, if you've got show notes or whatever, like fire me an email or something, you know, I can send you the link because this is open source, you know, you can actually read.

So there's a bit of debugging that went on. Someone was getting some very strange messages when they were running homebrew. And this is in the earlier days of Mac Os. So nowadays Mac ships with a thing called system integrity protection, which essentially means like, look, I don't care if you run pseudo, there's certain stuff on your disc that's more important and we're not gonna let you just like screw around with it.

So stay away. But before they had that, someone was trying to run home Homebrew, getting very strange error messages. And what was figured out was that they had managed to replace bin bash, which is, you know, on a Unix system, a relatively important thing for you to have somehow with no JS. So every time they were attempting to run a batch script, they were getting JavaScript errors in their shell.

So that to this day is my favorite issue I've ever seen on

Jonathan: Homebrew. Oh, that's beautiful. That is beautiful chaos. I love it. All right. Yeah, John.

John: I was just gonna say, just one of the things that I was like surprised about is I can't mention names, but several very large enterprises that make that make a lot of the core technology that we depend on have their own internal forks of brew.

Oh, yeah. And so, you know, they, they're basically maintaining an entire Parallel infrastructure where they're like reviewing everything themselves you know, to get at these like kind of supply chain story, like keeping things up to date vulnerabilities. It's just like unbelievable that it's, you know, brew is that important to them that they can't, they can't decide, Oh no, we just won't use this.

No, we actually, the only option we have is to maintain this ourselves internally as a totally separate fork. So that just kind of goes to the, you know, the idea that it's a very essential tool for a lot of developers.

Jonathan: Yeah, yeah, that's great. All right, so I'm going to ask each of you a final two questions, and that is your favorite text editor and scripting language, and we'll start with John.

John: I mean, this is pretty easy for me. I'm a Ruby developer so Ruby is my favorite scripting language. I, you know, I used to work at GitHub for close to seven years. And I was so happy when I joined GitHub because it was finally a company that used Ruby as like their main language. I had always been like a web dev, you know, my early days I was doing like PHP and like Java and stuff like that.

And when I moved into writing Ruby, you know, at work, it was like the best thing ever. And then I kind of have, you know, A soft spot for Pico. Okay. As my editor, I first, when I started writing code that was the first editor that I learned how to use on a Unix machine. I was running like a Gen 2 box.

Yeah. And old habits die hard. It's like still the thing that I just opened by default in my terminal.

Jonathan: Pico and not Nano? Yeah.

John: Pico, not Nano.

Jonathan: That's great. I

John: have an alias usually.

Jonathan: Makes

Mike: sense.

Jonathan: All right.

Mike: Mike. Yeah, so scripting language, I'm actually gonna disagree with John. So I use Ruby for like proper programming nowadays.

But if I just need to quickly solve a problem, I always go to Bash. Like me and, me and Bash, Bash has treated me so badly so many times. But yeah, I keep coming back. Like I don't know what it is. And yeah, as for text editor, like nowadays I feel like I'm, I wouldn't say begrudgingly, but you know, it feels like a lot of developers are on VS code now, and it makes just life easier for me to just follow the flow and go there.

But yeah, I'm still, I'm still keeping my eye on other things like the extension ecosystem of VS code is great, but like, you know, it's not the fastest thing in the world. And there's a text editor by an ex GitHubber. Called Zedd that is kind of up and coming, written in Rust. It's super duper duper fast.

And I've been playing around with that ever so often. It doesn't have quite all the features I feel like I need, but like, yeah, I, I have my, my hope for that as a potential feature option.

Jonathan: Yeah, absolutely. We, we interviewed a young man back a few weeks ago, building the amber language that is intended to be bash code with some of those bash pain points removed.

That one might be interesting to look at. We had a lot of, we had a lot of fun talking. I kind of like

Mike: the pain points at this point of everything bash does wrong is just, you know, it's like, it's almost like scar tissue that. It feels like it's part of me, you know?

Jonathan: Yeah. I'm, I'm trying to figure out, it seems like we either interviewed or we're going to, ah, I'm in contact with the guys from Zed about hopefully getting getting them on the show.

So watch for that. too. Guys, thank you so much for being here. I appreciate it very much. And it was, it was really fun to get to learn about, about homebrew, which, you know, it's been around for forever. And then work brew, which is a really, really fascinating project. The business that's been built and boy, hopefully hopefully it'll continue to go well.

And maybe here in about a year, we can have you guys back on and talk about what's happened since.

John: Oh, we love it. Thank you so much for inviting us.

Jonathan: Yep. Good deal. All right.

David: What

Jonathan: do you

David: think, David? Ah, I love it. I, of course, as we started at the beginning, I'm not a big Mac guy, but I'm interested in playing around brew on Linux.

Jonathan: Yeah. I tell you what really fascinates me the most is for my use is a brew in GitHub actions like that. I, I, I never had that thought. That is very surprising to me, but you know, as they describe what you can do with it, it makes sense that you know, you're, you're. Your GitHub runner may be running something very different than what your develop machine is.

And having this external package manager that can put the exact same packages on all of them, like that's, that's kind of compelling. So that's definitely something that I will have to keep in mind for the future that could be interesting to do. I like that. I, I'm also just thinking about the conversation we had.

I am, I'm impressed with the way that they are building Workbrew on top of Homebrew, and I, I don't know if you would call that, I don't think you would call that an OpenCore project. I don't think that's fair to call it that. But just that they have this very clear line of demarcation between the two.

And they're pushing features into homebrew as needed to make workbrew work. I think it's a good, I think it's a good model. And I think it'll, I think it'll serve them well. So, you know, looking forward to. Hearing about their success as time goes by.

David: Absolutely.

Jonathan: Yeah. All right. David, is there anything that you want to plug

David: before we let folks go?

Not specifically, but I always like to take the opportunity to plug club twit and the twit network. They're going through changes that I think are positive in the long run. Yeah. And we have fun over there. So come on over.

Jonathan: Yes, we've got, we've got our show that David is from time to time, but co host on.

And that's the untitled Linux show where we talk about all kinds of fun Linux news and open source news. And there's some, as we say, there's some cross pollination between floss and and ULS. Coming up on floss weekly next week, we actually have Pedrag Brady from CoreUtils, and we talked about the Rust CoreUtils a few weeks back, and I got an, I got an email that said, Hey, you know, we're the OG CoreUtils, we'd love to talk to you too.

So we've got them coming on, and looking forward to that next week. We'll be back at our regular time next week on Tuesdays, we recorded a little early today. And then, yeah, we, Appreciate Hackaday being the sponsor of the show, giving us a place to land. And you can follow my work there. The security column goes live every Friday morning, and that's always a lot of fun too, to keep up with what's going on in the world of security.

But other than that, just want to say, thanks. We appreciate everybody being here, catching us live and on the download. And we will see you next week on Floss Weekly.