Episode 356: Workbrew

18 March 2024

Interviewed by Mac Admins Podcast

The team from Workbrew joins us this week to discuss the challenges MacAdmins face with Homebrew at their companies.

Show transcript

0:00 This week's episode of the MacAdmin's podcast is brought to you by Kanji.
0:03 If you've ever enforced a security framework across your Apple fleet,
0:08 you know that it can be extremely tedious. Kanji makes this a lot easier.
0:14 Most MDM solutions give you the tools to help you manually achieve general security compliance.
0:21 But with Kanji's device management solution, the scripts, controls,
0:26 and settings needed to achieve compliance are already built in and organized into templates
0:32 so you can get going on day one. To quote a customer, Kanji has helped us achieve much
0:39 higher compliance with much better results, all while delivering a better experience for both
0:45 end users and admins. Check them out at kanji.io slash macadmins. That's K-A-N-D-J-I dot I-O
0:56 slash macadmins or join the Kanji channel on the MacAdmin Slack to say hi and see what they're
1:02 up to. Thanks again to Kanji for sponsoring this episode of the MacAdmin's podcast.
1:19 Hello and welcome to the MacAdmin's podcast. I'm your host today, Marcus Ransom. And Charles,
1:25 how are you going?
1:26 I am well. It's a stunning weekend. I got so much done. Joel and I started writing this weird
1:34 project for the Vision Pro. I blame Joel for my lack of spare time these days.
1:39 So you've got your Vision Pro replacement back. Have you managed to break this one?
1:46 I have not broken a second. I did print a Vision Pro holder to keep me from breaking anything.
1:55 So crossing fingers.
1:57 There we go.
1:59 And how are you, Marcus?
2:00 Well, I'm fine. I've been traveling for a week along with, well, not along with, but alongside
2:09 about a couple of hundred thousand Taylor Swift fans going to and from Melbourne and Sydney,
2:15 which, you know, so the airport was full of lots of people exchanging beads.
2:20 Access to hotels in Sydney where I was staying was challenging. So I've been dealing with a hotel
2:28 where the access card to my room would spontaneously stop working, taps falling off, interesting odors,
2:37 those sorts of things. So, you know, it's good to be home.
2:41 I don't remember the weird odors when I took my kid to see Taylor Swift. I do remember
2:46 some weird odors, like when I went to see the Black Crows, but I'm guessing they were very
2:52 different odors. I don't know.
2:53 Probably, probably. You know, I, yeah, exactly. Hotel odors, going to see band odors, very
3:01 different things. Usually don't spend too much time.
3:05 But we have great guests today, right?
3:06 We do. Let's talk about interesting things. So we've got the team from Workbrew here joining
3:11 us to discuss the challenges Mac admins face with Homebrew at their companies. So we're going
3:15 to talk about ways to cut down on IT busy work while also getting ahead with your engineering and
3:20 security teams, an uncompromising approach to engineering productivity and security posture.
3:25 So along the way, we're going to touch upon maintaining Homebrew open source project and
3:30 their approach to building a business around open source. So welcome to the podcast, everyone.
3:35 Thanks for having us.
3:36 Thanks. Hey.
3:38 Well, what we might do first is how about we get you to introduce yourselves and let us
3:44 know how you met and what got you to where you are now starting a startup.
3:48 Yeah. So I guess I can go first. So my name is Mike McQuaid. I'm the CTO of Workbrew.
3:56 And outside of that, I'm the project leader of Homebrew, the macOS and Linux package manager
4:02 for open source, which I've been working on for 15 years. I'm based in not so sunny Edinburgh
4:08 in Scotland. And I left GitHub where I spent a decade finishing as a principal engineer last
4:15 year to go and join John and Vanessa, my co-founders, to start Workbrew, our exciting startup doing
4:24 some interesting commercial stuff in the Homebrew space.
4:26 Hi. So my name is John Britton. I like to call myself a software developer, but really I focus
4:33 mostly on developer tools and helping people become better developers. So I got my start in this space.
4:40 My first startup that I worked at was a publishing company where I worked with Vanessa. I was a software
4:46 engineer there and we worked in building college textbooks for people in like a customized way that
4:53 was also open source. Following that, I joined Twilio and I was a developer evangelist there.
5:01 That was an excellent introduction to kind of the Silicon Valley startup scene. And then after that,
5:08 I joined GitHub to lead the GitHub education program. So while I was there, I created the GitHub
5:14 Student Developer Pack, which is a bunch of developer tools for students, built GitHub Classroom, and later
5:21 went on to lead all of developer marketing for GitHub up through the Microsoft acquisition. While I was at
5:26 GitHub, I worked with Mike and Vanessa very closely. And yeah, in 2019, I left to kind of go out on my own.
5:33 And a few years later, they both joined me and now we're working on Workbrew.
5:36 Love it. So I was just looking through my personal blog and I think the first time that I wrote an article
5:45 that included installing something with homebrew was 2011. And that was a long time ago.
5:55 So I guess package management to me was always a nightmare and homebrew definitely made it easier.
6:06 Do you guys want to take us through what homebrew is for listeners who maybe haven't used it?
6:11 Yeah, sure. I'll start with like a little bit of history, I guess. You mentioned 2011. So
6:17 homebrew was created originally in 2009 by a guy called Max Howell, who was, happened to be
6:25 working for a little start of Lost FM. That probably brings back some memories of
6:28 what was all the rage in those days. Scrabbling. Sure. Less, less of the rage nowadays. But yeah,
6:37 so he had played around with various Linux and Mac package managers and sort of got some inspiration
6:43 from various places, but didn't really like anything that he landed on Mac OS, I guess, which would
6:48 have been Mac OS X. I appreciate the audience of this podcast probably likes the level of pedantry that
6:54 we homebrew maintainers also like. I thought it was called Mac OS X. I don't think like.
6:58 Yeah, true, true. Yeah. Mac OS X. Thank you.
7:01 If you're going to be correct. Yeah. If you're going to be a pedant about it, like it's better
7:04 get it right. But yeah, so he decided to create his own thing, which ended up being called homebrew.
7:11 It was, if you could read the read me of, from his initial commit where he talks about the
7:18 beer theme and also that he consumed beer while he was creating the original beer theme, which
7:24 is part of the inspiration. So yeah. So what, one of the interesting things he did
7:28 with homebrew back in the day, it was kind of created, like GitHub was relatively early
7:33 in those days as well. And like, I think like pull requests, which are kind of people's primary
7:38 interaction with GitHub nowadays didn't exist when homebrew was first published on GitHub.
7:43 And Mac's had the idea of like, unlike the way most package managers work of instead of
7:48 he maintaining himself or like appointing maintainers for every package or groups of packages that
7:54 essentially it would be a bit more of a free for all. And he would kind of moderate, um, what was coming
7:58 in. So I guess I sort of knew Max through a friend of friend in London and I kind of heard about this
8:06 project like fairly early on and I kind of played around with it and it sort of matched my sort of
8:11 ideas for how package management should be on Mac OS, which, uh, essentially was use as much stuff from the
8:19 system as you can and try and make things fast and nicely optimized and care about nice error messages
8:26 and yada, yada, yada, all this type of stuff. Um, so yeah, so I started working on it in 2009
8:31 as well, uh, about maybe six months after the project kind of originally was created. I think I was
8:36 maintained at number three or something like that. And for my sins, I've stuck around that. I'm still
8:42 doing this stuff 15 years later. And I guess for those of you who don't know what homebrew is and
8:48 have never heard of it in any way or used it in any way, I guess the way I tend to describe it is
8:52 it's essentially like an app store for your terminal for open source software primarily, although it's
8:58 kind of slightly grown in scope since then so that it will also run on Linux nowadays. And it can also
9:02 be used to install, uh, like binary software that's like proprietary software, let's say like Google
9:08 Chrome or whatever you can install with a brew install Google Chrome.
9:11 Love it. And I feel like, so I've, I still use, um, that Ruby command that was posted
9:23 gobs of years ago, um, that curls it down from GitHub and runs the install. Is that,
9:29 is that the way that you would say is kind of the right-ish way to install it?
9:34 That's still the primary installation method. I think lots of very angry people on the internet
9:39 for a very long time have, would strongly disagree with the implication that it's the right way
9:44 because people don't like that. But I, I, again, I think homebrew is one of the first places to do
9:48 the, like curl this, the script of the internet and, you know, pipe that into your terminal approach,
9:54 which is now a really easy way to install a bunch of software. But yeah, nowadays homebrew also has
10:00 like a macOS like package that, um, and workbrew has our own enhanced version of that, which we'll,
10:06 I'm sure we'll get onto later as well.
10:07 Oh, for sure. Um, yeah, I, I guess the objections that people might have is that someone could be
10:16 masquerading the DNS and you can be installing something else, you know, or, or what have you.
10:21 But I, I get that. I, I hadn't even thought about that until you just said it.
10:25 But there, but there's good, you know, if someone's doing security properly, there's ways to
10:31 ensure that that's not happening and, you know, um, put steps in place, uh, which, which is generally
10:40 what brings us to the, um, the challenges that Mac admins have with homebrew. Um, most Mac admins will,
10:48 will either use homebrew themselves or have used homebrew, whether it be for, you know, personal
10:54 machines or machines that they're developing on. But when it comes to using and managing homebrew in
10:59 an organization, so this is something that, you know, can best be described as a little bit chaotic for
11:05 someone who's trying to have complete control and, um, consistency about a system, um, letting
11:11 developers have access to something that can, you know, add an update software outside of that
11:17 management tool can be a bit problematic. So, you know, what have you observed from Mac admins, uh,
11:24 trying to use homebrew in their organizations and how they've gotten around that?
11:28 I think there's the way Mac admins tend to kind of want to package and consume
11:34 software, like often, you know, PKG files and turning software that doesn't work that way into
11:41 that format. And the way homebrew kind of deals with this stuff to kind of consume PKG files,
11:47 like in some ways it's kind of looking through the same telescope from different ends. Like I think
11:52 the, the ends are generally the same, but the problem is, is that again, when you get into kind
11:58 of Mac admin land, like the way you're kind of generally used to doing things as you have something on the
12:04 machine, you know, some MDM provider say that's pushing PKG files down, which are run as root.
12:10 But then I don't know if this is something that you Marcus or yourself, Charles have experienced
12:16 personally, but the, the issue comes when you want to then run homebrew that way because homebrew
12:20 refuses to be run as root. Um, and if you, uh, it's, it's funny because if you want to know like a
12:25 little backstory behind that, like if we, I've always wondered.
12:30 Yeah. So the reason why is, uh, so homebrew relies on the Mac OS sandbox as the, basically the sandbox
12:38 that is used by like the app store and stuff as like somewhat of a kind of security measure to stop
12:44 kind of when you install packages, then be able to just have full access to your system. And the issue
12:50 there is that the, at least last time I checked, the Mac OS sandbox is severely limited or, and or
12:56 completely broken if you run it as root. So like that was the reasoning for there is that it's
13:01 again, like a bunch of stuff in homebrew, it, it could be maybe explained a little bit better, but
13:06 essentially like we don't let people do it because it's extremely dangerous and they run the risk of
13:12 on Linux. It's even worse because you don't have a sandbox there at all. So you're, if you're
13:17 installing software from source on Linux with a default homebrew configuration, like any make file
13:22 could just write or remove any file anywhere on your system at any time, uh, which is a little bit
13:28 scary. And again, like bring back to your question, I guess this is the, the Mac admin
13:32 perspective is like, you don't really like the idea of like random software running random things
13:37 as roots or as the user with unconstrained access to all their files and everything like that on the
13:44 system. Especially when you compare that to the, the general security principle of using a least
13:51 privileged user. So, you know, we won't allow users to be administrators on their machines so that they
13:56 can't install software, um, modify, um, things on the machine, whereas, you know, which is the way,
14:04 you know, you're doing things in homebrew where you're not using the root user yet. You're giving
14:09 the users the ability to install and update all of these binaries, which, you know, is, as you're
14:15 saying along the way that Apple have designed the operating system to allow users to have the
14:20 functionality that they need and get the most out of their machine without compromising the operating
14:26 system or getting in the way and preventing things from running every time they have an update. So
14:31 it's, it's a real challenge when most of our management tools are designed to stop people
14:38 doing things the wrong way. Um, and here comes a tool that does things the right way. And so many of
14:44 those guardrails then become challenging because somebody has read the instruction manuals in a way,
14:51 yeah. But also, I mean, it's not like this idea is super, um, new. It's just, I always felt like
15:01 homebrew had more of an atomic operation than like a pip or for Python or a CPAN or any of the other
15:10 package managers that I used because it could drop things from, you know, Ruby gems or just all kinds
15:17 of different tools into one central place. And then all of a sudden I have a binary that can run that,
15:24 that has all the dependencies just built. And, you know, coming from an era where we were trying to run
15:29 Linux on a desktop, you know, and life sucked, just trying to get a CD to burn of all those.
15:36 I remember those days quite well running Linux on the desktop. I started with, uh, I started with
15:45 Gentoo on my desktop and, uh, they had a package manager emerge. And at the time everything was
15:51 source built. And so installing KDE was like a three day prospect. Um, so that was kind of a nightmare.
15:57 I learned, I learned how to depend on a package manager. It was just a very, very slow and
16:02 arduous process to, you know, be able to get all those benefits. And when Mac, when I kind of like
16:06 made the transition onto using a Mac computer and, you know, Apple released OS 10, which was Unix based,
16:12 it was very obvious to me that the package manager was missing, right? It was like, oh my God,
16:17 how do I survive on this system? And I'm sure you've probably heard of Mac ports. And so I used
16:23 Mac ports in the early days. And for me, like it was very similar to using emerge. It was, you know,
16:28 get all the sources, build everything locally. And like a lot of the times something was not
16:32 configured correctly and it would not build and you'd have a terrible time. And so when I finally,
16:38 uh, I don't know, discovered homebrew for myself, it was, uh, like a total transition, uh, from,
16:46 you know, using what felt like an incomplete operating system to something that was more
16:51 like what I expected as a developer. Um, and yeah, just, uh, got into it, got started using
16:59 it like, uh, pretty much for everything, like, uh, leaning on all that stuff. But like, yeah,
17:03 like you were saying running, running, uh, running Linux on the desktop was just a different,
17:09 a different era. Yeah. And I thought it was never going to happen until, uh, Chrome OS,
17:15 I guess, you know, and then I'm like, Oh, someone finally did those right. So I mean,
17:22 maybe Ubuntu kind of, but not whatever, no shade. I mean, I feel like, I feel like using Mac OS with
17:28 homebrew is like a nice middle ground. It's like, you've got all the niceties of a Unix operating
17:33 system, command line access. You can run everything just like it runs on your Linux boxes and you have
17:38 a package manager, but you also have a system with drivers that work and you know, displays and network
17:43 cards that work right out of the box. Yeah. In a pre-rootless, uh, context, I agree. I think
17:50 the sandbox and the kind of breaking of all the POSIX compliance stuff started to shift that a little
17:56 bit and make it more of a closed ecosystem, but you can still do anything under the hood,
18:00 so this week's episode of the Mac happens podcast is brought to you by collide. You've probably heard
18:09 us talk about collide before, but have you heard that collide was just acquired by one password?
18:15 That's pretty big news since these two companies are leading the industry in creating security solutions
18:21 that put users first. For over a year, collide device trust has helped companies with Okta
18:28 ensure that only known and secure devices can access their data. And that's what they're still doing,
18:34 but now as a part of one password. So if you've got Okta and you've been meaning to check out collide,
18:41 Collide now is a great time. Collide comes with a library of pre-built device posture checks,
18:48 and you can even write your own custom checks for just about anything you can think of. Plus you can
18:54 use Collide on device without MDM like your Linux fleet, contractor devices, and every BYOD phone and laptop
19:03 in your company. Now that Collide is part of one password, we're only going to get better. Check out
19:10 Collide at collide.com/macadminspodcast to learn more and watch the demo today. That's K-O-L-I-D-E.com/macadminspodcast.
19:25 Thanks to Collide for sponsoring this episode of the Mac admins podcast.
19:28 So here you are a developer. And I mean, I think from many of the Mac admins that I talked to,
19:37 they're like, let's try to figure out how to block, you know, CPAN, PIP, BRU, etc. Simply because
19:44 that's a threat in a large environment where potentially that might be seen as the root of a
19:53 supply chain attack or something like that. So did you find that Homebrew was getting feature requests
20:00 or PRs that were sitting there trying to make it more compliant for Mac admins, I guess?
20:07 Yeah, there's two parts that I think are interesting. So one is the PRs and the other is like the supply
20:13 chain stuff. And so on the PRs, like, yeah, like this is something we've seen on and off for kind of,
20:20 I guess probably 10 years, particularly like in the early days, Homebrew was very much geared towards
20:25 engineers only really used by engineers and like, you know, random end users didn't really have any
20:31 interest in it. And also, I guess, even like the state of MDM and like actually looking after people's
20:37 endpoints was less mature and the communities who are more into Homebrew were less likely to be in
20:45 higher compliance environments like that, right? Like, and yeah, so that there ended up being and still continues
20:52 to be a bunch of requests of can Homebrew do this? Can Homebrew do that? Like, it would be nice if
20:57 it was more compliant with the way my organization works. And the issue that Homebrew's kind of experienced is
21:05 like the volunteers, because it is still a almost exclusively volunteer run project. I guess I'm
21:11 probably the one exception to that rule at this point. And they don't want to do a lot of that,
21:16 right? Like again, particularly like enterprise IT compliance, right? Like there's a reason people
21:23 get paid to do that rather than spending their evenings and weekends, you know, like Charles,
21:29 you were talking about your Vision Pro and stuff like that, right? There's a reason why you're probably
21:33 playing with that in your evenings and weekends rather than being like, oh, you know, I would really
21:37 love to read a SAML white paper this weekend because that's the most exciting part of my life, right?
21:43 Um, so yeah, so we have this interesting impasse effectively where people who are in the situation
21:50 of having to manage a fleet of Macs for their day job, like, and they have very real meaningful
21:56 problems they're experiencing due to Homebrew. And then you have the people who are actually running
22:00 Homebrew who are like, I don't experience these problems and I'm not particularly inclined to fix
22:04 these problems, right? Um, so this is, yeah, like, this is the interesting thing that I guess I learned
22:10 about open source. Like I previously worked at a consulting company back when I was a KDE developer,
22:16 partly because I was like, hey, they hire more KDE developers than anyone else. Like,
22:21 this seems like the greatest opportunity, right? Like I can go and work in open source and get paid to do
22:25 it. Like, isn't that the dream? And then I learned pretty quickly in that job at this consulting company
22:30 that like, actually the open source work you get paid to do is a lot less fun than the open source
22:36 work that the volunteers do for fun in their free time, because that's the stuff that like, it's not
22:40 getting done and someone needs to get it done. So someone pays someone else to get it done, right?
22:45 Like, and this is a, uh, you know, it's, it's maybe, uh, less of a pitch to work on this stuff,
22:52 but it is fun, honest. Um, but like, I think that's where we've ended up with this sort of interesting
22:58 conflict where, because there's no commercial relationships or money passing hands or that
23:03 incentivization to do this stuff, it ends up not happening. And the last, just to jump on your other
23:09 point, I think the other interesting thing is like from a supply chain perspective that like,
23:13 we, we have these words like package managers, right? That mean kind of radically different
23:17 things depending on the context. So I guess the example is you use like, uh, PyPy or NPM or RubyGems.
23:23 So the interesting thing with these ecosystems, um, where supply chain attacks are like a, a pretty
23:30 big problem is because anyone could upload anything at any time, basically. Right. So I can just,
23:36 no one is essentially vetting my work. If I have a popular package and I want to push a new version,
23:41 like no one's checking that version before I push it. And no one's checking that that version
23:46 matches what is on my GitHub or whatever, although there's a little bit of work happening with this
23:50 stuff now. Whereas in Homebrew's case, it sort of get, often gets conflated with those tools because
23:56 it feels like it's part of the same ecosystem. But every change that goes into Homebrew, a human looks at
24:01 that change and says, one of the Homebrew integers, it says, yes, this looks okay.
24:06 And it gets merged in before it happens. So we have a lot of automation that goes on
24:11 and we have a lot of external contributions that go on and stuff like that. But ultimately there's
24:15 30 people, probably fewer than 30 people in any given repository who have to say, okay, this looks
24:22 okay. And like that gets checked. And again, those people, yeah. And those people are audited and if they
24:30 are inactive for too long and they get their permissions get revoked and all this type of stuff.
24:34 So yeah. So there, there is a higher threshold for this stuff than, than the perspective is, but
24:40 still, you still have these problems of like, okay, the security supply chain may be less problematic,
24:46 but the features are not there. The features that we need as Mac admins.
24:51 I was speaking to somebody who was a Mac admin, um, just the other day and they quoted back to me,
24:57 you know, there are 17 different tools in my organization that people within the company can
25:02 use to install other things. Um, all different package managers, whether it's language specific
25:07 package managers or system, you know, system installers or things like that. And what was
25:12 interesting about when they quoted me that was that they also said that, you know, in the case of
25:16 homebrew, homebrew runs on the endpoint and rather than like, you know, in our code base and running
25:22 on, uh, like RCI devices or in our production deployments or whatnot. And given the fact that
25:28 homebrew runs on the endpoint, the tool that they lean on the most has been like their MDM or their, um,
25:33 other kind of endpoint scanning tools to make sure that that stuff is safe. And there's not really a
25:39 great story for how to do that with homebrew. Every person I've talked to has their own different
25:43 way that they've kind of like custom built or like, you probably have seen these gists where there's
25:47 like, you know, a couple hundred lines of scripts that people have been commenting on for the past
25:52 five years and keep getting reused. So yeah, it's definitely something that people are feeling and
25:57 talking about. But, um, like Mike said, it's not quite, uh, an interest for the open source
26:04 maintainers to want to work on.
26:05 And that's fair. I mean, I think the point about developers writing tool for develop tools for
26:11 developers and having fun doing it because it solves their specific need. I mean, if I was using
26:18 homebrew to do a task, to get something ready to deploy to devices that I didn't want homebrew on,
26:24 then I might just make a package out of what homebrew made by snapshotting the machine before and after,
26:31 and then deploying whatever changed in the middle. However, if you're working with a large team of
26:38 developers who are constantly asking for things, you can't keep up by compiling everything they need
26:44 on their behalf and then going back. So I think that's where something like workbrew kind of comes
26:52 into play in my mind. Um, but I don't know. So go ahead, Marcus.
26:57 Before we get into workbrew, I just thought, given that we've got three people who have
27:02 been involved in homebrew here, we've discussed how many different ways there are of doing things
27:07 and there's always different opinions. So I thought we thought it'd be great to get you to explain
27:13 how homebrew works and whether between the three of you, there's a consistent view as to how homebrew
27:17 works. So like most open source tools, we're going to get three very different opinions as to how
27:22 homebrew works. So do we want to maybe get down to brass tacks and have you explain for, for some,
27:29 for somebody who hasn't used homebrew or for somebody who is using homebrew to,
27:34 to explain from, from a nuts and bolts point of view, how it works?
27:38 So I think for all, all three of us, it's our, our interactions are all going to be,
27:44 are going to be quite different from like how we've been involved in the project. So like Mike,
27:48 you know, he's been involved for 15 years. He's a, you know, the project leader and, and, and does a
27:53 ton of, you know, every single day I see him working on pull requests and working on features for,
27:57 for homebrew. But, um, you know, in my experience, I'm more of a user, right? Um, my, my experience
28:03 with homebrew has been, uh, I set up my machine. I use one of Mike's open source projects called
28:07 strap, uh, to kind of write a bunch of bootstrapping scripts for my machine, set up my dot files.
28:14 Homebrew is part of that, install all the packages that I want to have. And maybe here or there,
28:18 there's a couple of packages that don't exist. So I've contributed packages. And then, uh, you know,
28:23 maybe there's something that doesn't exist in the brew command. And I've like made one or two
28:28 contributions to the actual command line tool. And, you know, I'm just a normal user for,
28:34 for all intents and purposes. Like I just, uh, you know, use it just like a normal developer.
28:38 Um, I think Vanessa's interaction has also been like quite different. So maybe you want to say,
28:43 let's talk about that.
28:44 Yeah, we just got back from FOSDEM. I don't know if you all remember developer conferences. Uh,
28:51 that was really, that was quite fun. And we also, we also had a chance to attend the homebrew, uh, AGM.
28:58 What does AGM stand for again, Mike?
29:00 Annual general meeting.
29:01 Annual general meeting where they get everyone together. If you're involved with open source
29:06 projects, you're probably familiar with this drill where you go over the sort of annual business before
29:12 the people who do the work. And, uh, Mike's been involved with this, as I think he said, for 15
29:18 years, he could have a teenager that is his, his, this open source project. Uh, and when we worked
29:25 together at GitHub, uh, something that he always appreciated, I think about our interactions,
29:30 he taught me get like over a series of zoom calls. Uh, and that was also, you know, my introduction
29:39 to the world of, of homebrew and, uh, and Mike's role in it. Uh, and then, but, but he was always
29:47 like, Vanessa, you just make things go like the, you, you make things happen. And so that's, I felt
29:53 amazing that he, you know, gifted his time and now he wanted some more of my time back. And so he asked
30:00 me to run, uh, for the product, for the PLC, uh, product leadership committee, project leadership
30:05 committee. And now I'm helping, I'm actually on a few different nonprofit boards here in Philadelphia,
30:12 helping them get their governance, right, get their goals, right, helping the trains run on time.
30:18 And so now I am doing that as a leader at homebrew.
30:23 I love it. And then your explanation of how it works, Mike.
30:28 Well, Mike, Mike might actually be able to talk to you about the actual nuts and bolts of
30:32 how it works rather than how we're involved in it.
30:34 Yeah. So, I mean, I guess like there's the technical side and the social side, like,
30:40 are you interested in, in, in one more than the other or, uh, both?
30:44 I mean, whatever you want. Um, there is a future question that we can bring forward of like,
30:49 hey, what's a cask?
30:50 Yeah, sure. Okay. Well, so I'll, I'll try and touch on that as well. Right. Uh,
30:55 so like social side, I think I mentioned before, like homebrew is, um, about 30 maintainers right now,
31:02 um, of people who work mainly in evenings and weekends. Like we, we've got a financial situation
31:09 such that, I guess I like to call it the open source, uh, curse of having enough money,
31:14 way too much money for stickers and not enough money to pay any individual really.
31:19 Yeah. So like we, we've started doing like stipends so we can kind of compensate people
31:27 a little bit for their work and stuff like that. But I mean, it's, you know, it's one of those
31:31 things where if you start, particularly those of us who do quite a lot of work on homebrew,
31:35 if you start trying to add up and do market rates and things like that, um, then it starts to get,
31:40 I don't know if either of you have, uh, Vanessa has also written a book. I wrote a very boring book
31:44 about Git about a decade ago. And I remember what a previous boss who talked me into, you know,
31:49 writing a technical book. I remember he once said, um, don't ever at any point, uh, try and calculate
31:55 how much time you've spent on it and how much money you make, because it will just make you very,
32:00 they're not related. It will make you very, very sad.
32:02 Perhaps an inverse relationship to those two things.
32:06 Exactly. So it's similar kind of vibes in homebrew where people are doing it for the love,
32:11 not for the, you know, very small amounts of money they get. Um, we've got a team distributed
32:17 throughout the world. You know, we've got people in Australia, Shetland islands of Scotland in,
32:22 you know, basically pretty much every continent in the world, I think, except, you know, Antarctica.
32:28 And, uh, yeah, like we collaborate mainly over GitHub and a little bit, we've got our private
32:33 space in Slack and stuff like that. And that team's kind of slowly grown from one person, um,
32:39 in 2009 to like 30 or so of us. Now it's been like 50 maintainers in total over that time.
32:44 Then we have a wider group of like about 10,000 people who've contributed at least like one pull
32:50 request at one point to something in homebrew. Um, in the earlier days of GitHub, like homebrew was
32:55 like one of the most like forked and contributed to projects. Um, and then we've got, we reckon like
33:00 tens of millions of users, however, uh, which some of those are, are bots. Um, but you know,
33:06 bots are just as important as humans to us who are maintainers. So we try and make their lives easy
33:11 to have feelings too. Exactly. Almost, almost more important in the automation world, right?
33:16 Yeah. Let's be, let's be kind because eventually they're going to be ruling over us all. So we want
33:22 to make sure we're, we're kind in the game.
33:23 That's why I keep telling the kid to be nice to A-L-E-X-A, but yeah. Yeah. So on the technical
33:32 side, homebrew is built mainly in Ruby. Um, again, that was a language that max liked to work in that
33:39 was kind of available on Mac OS 10 in the kind of early days. Like nowadays, homebrew ships its own
33:44 Ruby because the Mac OS version is too old and all that type of stuff. It has smatterings of bash and
33:51 Swift here and there. And obviously we kind of have to play around with Apple technologies to do stuff
33:56 like building the PKG installer and all this type of stuff. And then essentially the way most people
34:03 interact with homebrew most of the time is just installing some software. So to do that, you would
34:07 type, you know, if you want to install the W get the like open source downloader, you would type brew
34:12 install W get, and then it will like download the binary package that we, that homebrew kind of
34:18 architecture is built for you. It would pull it down to your machine, extract it and get it ready
34:23 to go in like, you know, under a minute basically. Um, so originally homebrew was all built from source
34:28 on your machine. I guess like John mentioned earlier, like gen two and emerge and stuff like that. And,
34:34 you know, back in the good old days of Intel max, your, your fans would be like spinning frantically,
34:40 something like some sort of space shuttle takeoff for a few minutes, uh, while your software was built.
34:44 And then at the end, everyone would have essentially the same artifact. So it was a huge amount of waste
34:49 of time, resources, electricity, heating, space shuttle sound effects, et cetera. Um, so eventually we
34:55 moved, we introduced these things called bottles, which are, um, like binary packages for homebrew,
35:01 essentially. So pre-compiled stuff that you can download. Um, and the instructions to install
35:07 the package that kind of would be programmed by people in this nice little Ruby domain specific
35:12 language were called formula. Um, so formula produced bottles, which were then downloaded.
35:18 So later on, there was this other project coming to the casks. You mentioned Charles,
35:21 um, where there was this kind of adjacent project to homebrew called homebrew cask,
35:27 which thought, Hey, homebrew is nice, but like homebrew is just all installing open source software
35:31 built from source, whatever. But like, wouldn't it be nice if you could install Google Chrome
35:36 by doing brew install Google Chrome. Um, so they had their own little command. It was like brew cask
35:40 install Google Chrome. But I think five or six years ago, um, we sort of, the two projects were merged by
35:47 a Google summer of code student that kind of worked with us. And yeah. And then nowadays, essentially the
35:52 interfaces are the same. So you can type just brew install Google dash Chrome, and then that will install
35:57 Chrome down on your machine and effectively produce the same output as if you'd installed it yourself,
36:03 download it off the website, double click the installer, click through all the buttons, whatever.
36:07 Like it's, that's when I guess with the cask stuff world, this is when we're getting a lot more
36:12 overlap with the kind of Mac admins world, because often we are taking the same pkg files that you
36:17 might have previously been deploying via your MDM tool of choice. And then we're using those same
36:23 pkg files and installing them in the same way. So I think there's, this is where they're kind of
36:28 probably comes the most overlap and the most opportunity for kind of combining efforts,
36:32 but also I would imagine I've never been a Mac Avenue myself, the most potential cause for
36:37 frustration that no, they should be, they should really should be getting this pkg file through our
36:41 way of doing things and not through the Humber way of doing things.
36:44 Except when you're managing machines that developers use. And then it's like trying to manage machines that
36:50 graphic artists use and being like, no, we have to install all your Photoshop plugins or, um, video editors and we
36:59 have to install all your, you know, uh, plugins for the various video editing tools. Like, it's just a nightmare.
37:11 Are your employees practicing safe SaaS? Find out with nudge security. Their patented approach to
37:16 SaaS discovery gives you a full inventory of all apps ever introduced by anyone in your org in minutes,
37:22 no agents, browser plugins, or network proxies required. The best part, you don't even have to know what
37:27 apps you're looking for. After a quick one-time setup with your email provider, nudge security
37:32 discovers and categorizes every SaaS and cloud account, giving you a full inventory of who has access to
37:37 what. You'll see which accounts have MFA enabled, which apps are enrolled in SSO, and an inventory of
37:43 OAuth grants to help you identify risky scopes and revoke grants if needed. Nudge security also includes
37:49 playbooks to automate tedious time-consuming tasks like conducting user access reviews, off-boarding
37:55 employees, orchestrating SSO onboarding, and more. Start a free 14-day trial today at nudgesecurity.com/macadmins.
38:04 So fonts sort of ended up with the joys of font management tools to overcome that. And I guess
38:13 that probably then brings us to work brew with the idea of, well, rather than making this go away and
38:20 saying, all right, no homebrew, which is what we see in some regulated industries, which can make it
38:26 incredibly frustrating for the developers who are used to working that way, frustrating for the Mac admin,
38:32 who now has a list of 400,000 items they need to manage and deploy on the endpoint for the users.
38:39 So, you know, do you want to go through work brew for us and talk about, you know,
38:44 how you're trying to, you know, make things more organization friendly?
38:49 Um, so you mentioned fonts, you should check out homebrew fonts. And then the other thing on homebrew
38:53 that I was going to suggest that Mike might want to mention is brew files, because brew files are a
38:58 super under, like underutilized feature in homebrew. Um, so I don't know, uh, Mike, if you want to say
39:04 anything about that at all.
39:05 Yeah, I guess I could mention that. So brew files, uh, are inspired off this, this package, uh,
39:12 sorry, this repository that's part of homebrew called homebrew bundle. Um, and that lets you have
39:17 a command called brew bundle, which runs a brew file that was sort of inspired by like gem files,
39:22 essentially. Um, for those of you who've kind of played at the Ruby ecosystem, if you haven't,
39:26 it's, if you're in, in NPM land, if you've played with that, it's like package.json files. If you've
39:30 not used either of those things, essentially it's a list of packages. So it's a, it's a way of
39:35 interacting with homebrew and using homebrew, but in a kind of different way. So instead of like
39:39 manually running a bunch of commands or having a script that runs this command and this command,
39:43 this command, instead in a brew file, you can say, well, I want these formula. I want these casks.
39:48 I want say, you know, Postgres if like the database, if you want to have that installed,
39:53 I also want that to be started up like as like a daemon running in the background. Um,
39:58 and various things like that, that you can effectively specify. You can also install stuff
40:03 from the Mac app store and stuff like that. And it basically allows you to specify that in this brew
40:08 file, like in a declarative format. So you can, instead of like having a script that individually
40:13 runs a bunch of commands, brew bundle lets you say, okay, just what I want is everything
40:19 in this file to be set up how I say it will. And you can run brew bundle or brew bundle check
40:25 to say like, Hey, is everything in place there? And that's a very, very quick operation to do.
40:30 And then the, this is nice for kind of, I guess, two ways, like John mentioned this project strap
40:36 I work on. Um, it's my kind of the, probably the only, uh, personal open source project I've ever made
40:41 that has had any sort of, um, repute, I guess. Um, so what that leans on is using this idea of you
40:48 have a brew file of everything you want installed on your machine, like a global brew file, we would call
40:52 it. And then I can say, here's all my formula or my casks or my Mac app store stuff. And then basically,
40:59 like I want, when I provision a new machine or even just when I'm, you know, doing updates and
41:04 restoring myself to a consistent state, here's all the stuff I want you to install. And I can kind of
41:09 commit that file in a repository. That's if you want to go look, I guess we could put it in the show
41:13 notes. You can see like my brew file in my dot files repository that kind of contains Mike's canonical
41:19 list of stuff that he has installed in his machine right now. But you can also, and we use this a lot
41:24 more extensively at GitHub. You could also, if you're kind of working on a bunch of different projects,
41:29 have like one brew file per project. So you could say, okay, well, this Python project uses Postgres,
41:34 it needs Python, it needs wget maybe. And then we also have in the same company, a Ruby project that
41:39 needs this tool and this tool and this tool. And again, there's some overlap with the kind of Mac
41:45 admin space here, because I'm sure, again, you see this world where when organizations grow and
41:52 particularly developers are sometimes very pernickety about what stuff is or is not on
41:56 their machines, right? You don't want to install all of the Ruby stuff for the Python people,
42:01 and you don't want to install the Python stuff for the Ruby people. So it's kind of nice when
42:04 you can segment these kind of groups. And like doing that per project or repository with brew files was
42:10 a nice little way of doing that.
42:11 And I guess if you can do all that stuff in a declarative fashion, if it's just a JSON file,
42:19 basically, does that make building the agent for work brew a lot easier? Because now you've got this
42:27 kind of declarative framework to just plug in and, you know, you send a command with the agent and you
42:32 say, do that, do a thing. And then all the compilation is done on the client side. And now it's not
42:40 something you have to go through in too much depth, maybe with a separate work to build or something.
42:47 Yeah. I mean, the way homebrew works in this way does make things a lot nicer in the work brew space.
42:54 And I guess you mentioned the work brew agent. So that's a nice, I guess, segue to like the way that
43:00 we're building work brew. So we have some big ideas for what we're doing in the future. But right now,
43:06 like the kind of the stuff that we have in private beta essentially is built up of these kind of three
43:13 components, which combined we kind of call work brew. So one is the installer. So I mentioned earlier,
43:19 homebrew has its own like PKG installer, which has essentially worked pretty similar to the kind of
43:26 the download things off the internet package, where the disadvantages are that it needs kind of an
43:33 internet connection, just like fully set up homebrew along the way. You need to have a user that's
43:37 already set up on the machine that is being run with and stuff like that. So it kind of knows to put
43:44 the right stuff in the right place. Whereas the work brew installer is used to set up both homebrew and
43:48 work brew. And it runs homebrew as like a separate work brew user. And as a result, it doesn't need
43:55 you to have provisioned any user on the machine already. So I guess that's one advantage from
43:59 the outset is that if you're doing like a first provisioning of a machine, like all the kind of
44:04 automated stuff where you, you know, it's integrated based on your serial number and pulls everything
44:09 down and sets up the machine for the new hire, exactly how you as the Mac admin would like it to be.
44:14 You can have work brews install and set everything up that way. So like that's, that's, I guess,
44:19 a nice starting point. And it's also designed such that that installation process, you have a fully
44:23 working homebrew after then, which doesn't need to immediately then fetch something from the internet.
44:28 So the work brew installer, as well as installing homebrew, installs this thing we call the work brew agent
44:37 on the machine. So this kind of provides two roles essentially. So one is, it makes that I mentioned
44:43 like homebrew is now running as a separate work brew user on the machine. Like my goal is, I guess,
44:50 from a developer experience perspective is always to kind of try and make things absolutely transparent
44:54 and seamless as possible. So the agent kind of does some sort of essentially like proxying and managing
45:01 of, of homebrew such that you can just run brew. It's actually running work brew instead of running
45:06 homebrew, but it passes everything through and everything looks exactly the same as normal homebrew,
45:11 except when you install stuff, instead of seeing a little beer mug, you see a little coffee cup now
45:15 instead. But other than that, it's kind of managing all that. But then it also runs as a daemon in the
45:20 background, which is basically monitoring what you have installed on your machine. And then
45:26 periodically it reports that up to what we call the work brew console, which is essentially our cloud
45:31 centralized like location that's used for kind of managing and reporting that back.
45:35 So there's kind of two way relationship there between the work brew agent and the work brew console.
45:39 So the work brew agent is periodically sending information to the console saying,
45:44 what packages do you have on your machine? What versions are those packages at?
45:48 So that we then on the work brew console can say, okay, well, Charles has this package installed.
45:54 It's actually really outdated. And we might happen to know that like this version of this package
46:01 has a security vulnerability. So we can then go and say, okay, well, Charles needs to update that stat.
46:07 So previously, like prior to work brew land, that might look like you,
46:12 if you even had a way of figuring out that Charles had this outdated thing, I've seen some
46:18 very pretty horrendous scripts that people have had to try and run through their MDM provider to work
46:23 around the fact that homebrew refuses to be run as root and all this type of stuff to get this
46:27 information back and try and scrape it out of homebrew's JSON, whereas we provide a nice, easy web interface
46:33 instead. So you might have at that point, then you then have to have another hacky script that you
46:38 might've used to then go and try and upgrade something on, on Charles' machine. Whereas because we have this
46:43 two way agent relationship, you can then just say, okay, just upgrade this from the console
46:47 on Charles' machine. Tell me when it's done, show me the logs, show me whether it passed or failed.
46:52 And then you have this kind of ability to essentially just make sure that Charles' homebrew installation
46:58 is set up the way that we want it to be. It's configured the way we want it to be.
47:01 It's, we can run the commands that we need to run when we need to run them. And we're kind of able to
47:06 kind of monitor and make sure that kind of, if there's any old versions or vulnerable versions,
47:10 or even just software, we don't want to be running on Charles' machine. We can kind of see that. And then
47:16 you as the Mac admin can then take whatever actions you want to mainly through the Workbook console itself.
47:20 Love it. Yeah. There's probably plenty of people who think I shouldn't run any software on anything ever
47:26 again. Including Apple when they shut down your Vision Pro almost immediately. That's what happened,
47:33 right? Oh yeah. I, I went to do my first spatial capture and it just never recovered. It just stayed.
47:41 And I think I'm doing a thing, but I'm not. And you reboot and factory, nevermind. Moving on from that.
47:48 I'm getting over the trauma as we speak, mostly because I have the device back in my grubby hands
47:53 and I'm compiling code for it again. By the way, physics. Oh my God. Any kid who ever says,
48:00 I'm never going to use this when they come home from geometry. Yeah, right. You've never tried
48:06 right. Augmented reality code. But moving on from that. This week's episode of the Mac admins podcast
48:15 is brought to you by SIT. Hello Mac admins. Let's talk about the backbone of efficient IT operations,
48:23 understanding how your systems and processes work together. Our sponsor SIT brings you a game
48:30 changing solution, unified IT infrastructure. Picture this, a world where your IT systems seamlessly
48:38 connect, empowering you to optimize and streamline operations, ultimately reducing downtime and boosting
48:44 efficiency. SIT's unified IT infrastructure offers a panoramic asset inventory view, allowing you to track
48:53 and manage your assets effortlessly. Monitor your SaaS applications with ease and get a comprehensive usage
49:00 view, ensuring everything runs like a well-oiled machine. But here's the real magic. By integrating your
49:07 IT infrastructure, SIT provides invaluable insights for internal service improvements. It's like having
49:14 a crystal clear roadmap for enhancing your IT ecosystem. Ready to unify your IT operations? Dive into SIT. Visit SIT.io.
49:25 That's S-I-I-T.io to explore how SIT can transform your IT infrastructure. Thanks again to SIT for sponsoring this
49:36 episode of the Mac admins podcast.
49:37 So I don't know how you know how many outdated packages I have on my home boxes, but let's talk
49:45 about policies from the console. So I have a developer who has an outdated version of a formula
49:53 with a known security vulnerability or something like that. You mentioned that there are certain
49:59 steps that you can take. I guess, what other restrictions can I apply and what kind of
50:06 remediations can I put in place, if that makes sense? Because you might not want to just say,
50:12 oh, and install the latest version of this library or something because
50:17 it's a developer that might break my bills. I don't know.
50:20 Consistency is a goal, I guess.
50:24 So you said something that was really interesting a little bit earlier, which is, you know,
50:27 developers are special in some kind of way, kind of like how the creative folks are or,
50:33 you know, the video editors or the people using Adobe's tools. And that's right. Like they do have
50:40 different needs than the other personas kind of at your company. And something that we've uncovered
50:45 from talking to lots of different like Mac admins and talking to lots of different developers and
50:49 also talking to a lot of different security people is that as an organization grows and adds more and
50:55 more and more endpoints where homebrew is installed, all three of those personas have needs that come up.
51:00 You know, from the security perspective, it's how do I mitigate the exposure to a critical
51:05 security vulnerability that was just announced? How do I quickly lock that down? From a developer's
51:09 perspective, it's, you know, how do I get my machine up and running on the first day of work
51:13 or when I start working on a new project really quickly without having to deal with some kind
51:18 of a policy of asking for the ability to install something that I need to do my job? And from the
51:24 IT person's perspective, it's, you know, how do I make sure that I'm providing a great service,
51:28 a great level of service to everybody in the company while also like making sure I tick all the boxes,
51:32 right? And so this is something we spent a lot of time talking about and thinking about.
51:36 And I think Mike has a really good perspective on this as well, which is that we always want to be,
51:42 you know, improving the lives of all of these different stakeholders while never, you know,
51:46 compromising on how the existing, like how users are already accustomed to using homebrew and what
51:52 they expect out of homebrew. So I just wanted to kind of like get ahead of the conversation you were
51:57 saying about like policies and whatnot with our philosophy of, you know, how we approach this. And so,
52:02 you know, there's a lot of different things that we can do to solve the problems that you're
52:06 trying to solve. And, you know, for example, if something goes out of date, you know, Marcus
52:12 was saying, but we can't just change the version out from under them, they might be reliant on that,
52:16 right? So I think that there's definitely different kind of postures that organizations can take,
52:22 and we want to support the ability for different organizations that have different needs to take
52:27 a different posture. So maybe, Mike, I think you wanted to continue a little bit more about,
52:33 you know, the practicality of like how to do some of that stuff.
52:36 Yeah. So essentially what we have today, like we're, as I mentioned before, we're in private
52:43 beta and we're kind of working with some kind of customers we have right now, and we're actively
52:47 looking for more of this sounds interesting to you to kind of collaborate with us as design partners.
52:52 But basically, like we, an example of a policy that we have right now is the ability to say,
53:00 and this is in our kind of little demo on our website, say, hey, we don't want to let you
53:04 install anything with these licenses. So this is something, again, I've kind of heard in Homebrew
53:09 for a very long time, is that there's some companies that just do not like, say like,
53:14 HEPL v3, right? It's a license. That's, you know, it's not one of those podcasts where we can
53:19 unfortunately nerd out on the open source licensing for too long. But the TLDR essentially is that it's
53:25 a license that is very hard to comply with. And a license where if you accidentally use that in
53:34 your proprietary software project, like, you're potentially in trouble, right? So some organizations
53:41 have found it easier to just say, hey, like, we just don't want anyone to install using this license
53:46 ever, right? So with Workgroup, you can just say that, like, you can configure that essentially for
53:51 your organization. Like, you say, yeah, just forbid this license. And then when people try and install
53:56 using that license, it will say, no, sorry, you can't do that. And that, to me, like, that's an example
54:02 of something where the licenses are relatively, like, minimal enough that AGPL v3 that there's,
54:09 you know, it's fairly reasonable to just say, okay, well, you just can't do this. But then when
54:15 you get beyond that, we essentially, we're building out a lot of flexibility here right now. And we
54:20 haven't, we're essentially figuring out with individual customers what their individual policies
54:25 want to be. And as John mentioned, that's going to kind of differ. But we're trying to make sure that
54:30 as we do that, that, like, any policy is essentially, as John mentioned, not stopping people from doing
54:36 their job, but at the same time, meaning that you can kind of get the compliance needs you want.
54:42 And the worst case scenario, I think, for everyone, which again, is what we're trying to address,
54:46 is I'm sure the developers hate it if you just say as an organization, hey, we just ban Homebrew,
54:52 we just don't let you use this, right? And I'm sure as, like, Mac admins, like, you don't want to be
54:57 doing that as well, right? Like, that's, I can only imagine that's a sort of last resort that makes
55:02 you not feel great when you're having to say, hey, people want to use this software, but we just can't
55:07 let them at all. It's, like, not a good outcome. So to us, like, we're trying to deliver the best we can
55:14 to both of those groups at the same time, basically. Like, I think we have an offering, even right now,
55:19 that makes the life's better for IT admins and security people and engineering people. And I've been
55:27 very determined since day one that we do not build anything that looks like a, you know, crippled
55:35 version of Homebrew, because that's what's, you know, required. Because ultimately, people won't want
55:40 to use that. So that doesn't, again, serve the interests of the IT admins or the security people
55:45 either, because it's, you know, it's not the same as maybe banning Homebrew entirely, but it's not
55:51 great. So, like, we're building, trying to build something where, right now, we're building essentially
55:56 Workbrew to have feature parity with Homebrew for an engineer. But as time goes on, we expect Workbrew
56:01 will be a better version of Homebrew for the engineer as well, and that they would actively rather be using
56:06 this, and the IT admin would rather be using this, and the security department in your company would
56:11 rather you be using this as well. So rather than saying we don't allow you to use Homebrew in this
56:17 organisation, it's like, this is how we implement Homebrew in this organisation. If there's anything
56:24 that's not giving you what you need on your machine, here's where we put in the internal feature requests
56:29 or requests for, for things that you need to be able to do on, on your machine. And this is what our,
56:35 you know, approval process is to get, get those things on your machine.
56:38 Exactly.
56:39 Yeah. And for, for an example, I'm sure you've seen engineering teams where when you first,
56:45 you know, you first set up the project, there's a checklist, maybe there's like, you know,
56:49 a read me document, it's one or two pages, and it says, first make sure you have brew installed,
56:53 then install these 15 packages, you know, then make sure you like start these services and do this
56:58 and that and the other thing. And the kind of like better world for the engineer is that stuff's just
57:05 automated. It just works. And the better world for the IT administrator is that stuff's always up to
57:10 date and working with, you know, the code bases that they're working on. And if there's a security
57:16 vulnerability, you know, the security team gets a notice and you know how many endpoints are
57:21 affected, who hasn't updated yet, you can nag them, or you can, for example, you know,
57:26 I had a customer that I spoke to that rather than enforcing the policy of
57:30 blocking something from happening on their machine, or stopping them from installing something,
57:37 or even updating software for them, instead, their preference is to send out an alert to that
57:42 end user and say, hey, you're on X version, you need to be on Y version as soon as possible.
57:47 If it's not done within 48 hours, you'll be blocked from our VPN, right? And so that's like
57:53 a different kind of enforcement mechanism than saying, you just can't do this thing. Instead,
57:59 it's like, hey, this is very important. As an organization, we take security very seriously.
58:03 We take our, you know, compliance very seriously. Please do the things that you need to do to have
58:07 good practices. And if you don't, it's not that you're not going to be able to access your machine,
58:13 but you're not going to be able to access production. You're not going to be able to access any of these
58:16 machines that have highly sensitive information on them. Um, because that's, you know, and they
58:21 give you the out, you know, they give you the out upfront to say, please fix this now.
58:24 So something you mentioned just then, which, which really resonated with me is the idea of sort of
58:30 automating that configuration and setup of developer machines. There's been so many scenarios where
58:36 I've been working with organizations, they're going from hand-built machines to using MDM for
58:42 zero touch enrollment, and everything's great until we get to the developers. And then I get handed that
58:48 read me file you mentioned there, and they're going, oh, can you automate this to build it? So,
58:52 you know, it's quite often a set of seemingly manual processes, although they may be leveraging some
58:59 automation tools. So you go through and build out orchestration for that to be able to be
59:04 automatically set up on the machine. And then you go and get them to start testing it. And they're like,
59:08 oh, that's out of date. Um, that was what, that was what it was two weeks ago when we gave you that
59:14 file. Now it's something else. And you go through and update it and then find that it's changed again.
59:18 So this idea of being able to decouple the building and configuration and securing of the machine
59:24 in general from the setting up of that developer environment with things specific for that
59:30 even team. Because that's also when you discover that, great, that read me file was only for this
59:34 team here. They forgot to tell you that, you know, because it's all about them. And then there's the
59:40 team next door that doesn't have a read me file. They use a whole other different way of provisioning
59:44 their team. So that way to be able to get that granular configuration and, you know, have that managed and
59:52 updated by people who have that deep knowledge of what those particular teams need in conjunction with
59:58 security, operations, those sorts of things is, you know, a really exciting prospect for those of us who
1:00:05 have tried to make that a better experience with tools that maybe weren't designed properly around that.
1:00:12 I've heard this story a bunch of times in talking to different like IT admins, Mac admins, and the
1:00:19 story of my zero touch deployment doesn't work with Homebrew is like super common. Like you have to
1:00:25 have the account already set up. You can't do it during, you know, the enrollment phase. You have to wait
1:00:30 until it's done, which leads to that manual, which is five pages of steps that you have to do manually.
1:00:34 Now with Workbrew, our goal is to say zero touch deployment is totally possible. You get Workbrew installed,
1:00:40 the agents there, and then imagine you have an engineering team, or you have five different engineering teams, and
1:00:45 they have certain dependencies that they need installed. They can self-manage that via Workbrew for the entire
1:00:50 team. So, for example, a, you know, a lead engineer on a project might say, "What we need in this situation is
1:00:58 different than it used to be last week." And they go and they make the change, and then that's shared out
1:01:03 automatically with everybody on their team, right? This is definitely something that's possible, you know, for us in
1:01:09 the future. Right now, our main focus area is like on the Mac admins needs. So not serve the Mac admins
1:01:17 needs without, you know, hurting the experience for the other folks involved. And then kind of as we
1:01:23 continue down this path, it's things like we were just talking about, like helping with better development
1:01:28 environment set up and, you know, doing different things around security, vulnerability scanning,
1:01:33 or CVE detection, or detection and remediation and things like that. So yeah, definitely.
1:01:39 Yeah.
1:01:41 Correct me if I'm wrong. I can get, because I think I've done this, a dump of all the licenses used from
1:01:50 stuff that's been installed by Homebrew on a machine, right?
1:01:53 That's a thing. Yeah. So you've already got all that in JSON, and you've got this declarative
1:02:01 environment. And so now you can just build a policy engine by doing a little regex on those things.
1:02:07 And so if people have other policies they want, then that's just a matter of, let's do some more of that. And, or let's
1:02:17 build a framework where you can just insert your own fields and allow for, you know, globbing or whatever in there. Right?
1:02:25 Well, yeah. And of course, this is the beauty of the relationship we have as well, in that building some of these features,
1:02:31 like you mentioned, like what's in the JSON and what's not. And this is all, you know, publicly exposed stuff where
1:02:39 in theory, Charles, you could, you know, just bang out your own script to do a similar thing to the workroom console
1:02:47 does or whatever. But I guess what we've been finding, I guess, I don't know how Charles and Marcus and John
1:02:55 and Vanessa are going to groan because they've heard this, me make this metaphor about a billion times at this point.
1:03:00 But, uh, like how much you've played with like modern Lego. Right. Whereas when I was younger,
1:03:05 it felt like Lego was a lot more kind of modular and there was like, you know, like a bunch of different bricks,
1:03:12 a bunch of different components. You bought a thing and you could like rebuild it in different ways.
1:03:16 But like the Lego my six year old plays with essentially has two worlds, right? It either has the, you go to the Lego store
1:03:23 and you buy a box of like 500 bricks and then you just build those bricks into whatever monstrosity you want.
1:03:29 Or there's like the hyper customized, like this is a Velociraptor.
1:03:34 And this is the only piece of Lego that has this particular Velociraptor claw or whatever.
1:03:38 And I guess like I see what we're doing with work for the open source project in some ways, um, as being comparable, I guess we've
1:03:47 already banged on the Linux desktop here a little bit. So I'll, I'll bring out my favorite Linux desktop quote, which was, uh, Linux on the desktop is only free if your time is worth nothing.
1:03:57 Um, I remember that from back in the day. And there's a similar one here. I think where like, yeah, I mean, sure.
1:04:06 Like in your organization, could you build all this from scratch using the open source project and all the open data that's available? Like, yeah.
1:04:12 Yeah. And I also hope your time is worth nothing because that's going to take you forever.
1:04:17 And you're going to have to kind of, you know, you probably don't have the level of expertise with the open source project to be able to do that.
1:04:23 Whereas even while we've been building work brew, this is the nice kind of collaborative aspect I have for my CTO hat.
1:04:30 And my project leader hat is, you know, there's some stuff sometimes where we're like, Oh, to solve this policy problem, we need to have more stuff in the JSON that homebrew outputs.
1:04:40 And it's like, well, I can then just make a PR to homebrew and then say, Hey, other homebrew maintainers, does it seem reasonable that we had this JSON field?
1:04:48 And they were like, sure, let's add this in. Right. But it's like, but are, you know, in your organization, are you going to do that?
1:04:54 Are you going to have the confidence and know how to do that? Whatever. Like, maybe, like maybe.
1:04:59 Yeah. I wouldn't want to do that, but I also wouldn't want to maintain my own separate agent.
1:05:05 If I can pay someone else to have that sovereign agent and console provided that they're SOC 2 compliant or whatever other things that, that I need my organization to comply with, you know, so.
1:05:20 Also brings in the concept that I love Rich Troughton's term of this, the lottery bus, rather than saying someone getting hit by a bus, they get hit by the lottery bus.
1:05:28 So you have that person in your organization who would love nothing more than to spend that time building out all of that information.
1:05:36 And I've been in this position before where somebody has moved on to another role or they've won the lottery or whatever, and then you're presented with their code.
1:05:44 And it's like, this is your job to maintain this and you're reading it and going, I'm not smart enough to be able to do this.
1:05:51 And I don't have the patience to become smart enough to be able to do this.
1:05:55 So, you know, having an organization that is going to be looking after that for you so that you're not at risk of either having someone who can't move on to more productive things to be doing with their time or that person no longer being there and then being caught between a rock and a hard place.
1:06:15 Totally.
1:06:16 So let's talk security.
1:06:19 So have you put anything into Workbrew to try and make it more secure than regular Homebrew to give that functionality to the organizations that are using it?
1:06:29 Was there anything you've found that was missing in Homebrew?
1:06:32 Yeah, so I mean, the biggest thing, as I mentioned before, is like that Workbrew is run by it in its own separate user.
1:06:39 And so, you know, as I said, Homebrew relies a certain amount on the macOS sandbox and stuff like that.
1:06:45 But there's a degree of just separation there, which is essentially that this stuff is not we've never seen a lot of stuff exploited out there in the wild.
1:06:57 But there's ways in which the Homebrew security model had a certain degree of trust of the code being run as the same user, which we wanted to go a step beyond that with Workbrew.
1:07:08 It serves two purposes in some ways where both you have the multi-user system perspective, you have the ability to kind of provision that Workbrew user on boot before the user may have even chosen their username.
1:07:19 But you also have the separation of saying Workbrew is running over here in its own little user and it's not able to just like read and write arbitrary files from, you know, my documents folder or my iCloud library or whatever it may be.
1:07:36 And that that that separation is a little bit more clean and better.
1:07:40 And as I said, that that's the one like the way it actually works that we consider to be more secure.
1:07:46 But then there's also just the kind of the increased security posture of in Homebrew, for example, like you can disable auto updates.
1:07:53 And then if you say, hey, which packages are outdated that relies on your like local essentially store of which packages are up to date and not up to date being itself up to date.
1:08:06 So you can end up in slightly confusing user configurations where it's like, hey, well, we have Homebrew says all my packages are up to date and there's nothing to worry about.
1:08:16 But actually, we know in Workbrew land that like because we pull directly from Homebrew sources itself that like, OK, well, you say that version one point two is the newest on your machine.
1:08:29 But we know one point three was already released and we know that there's a critical vulnerability or whatever.
1:08:34 So like we know that not only do you need to upgrade that package, but you also need to upgrade your like definitions on that machine of what the packages are.
1:08:42 So essentially, we have a lower level of trust in the data on any given machine and instead like a centralized approach where we can tell like what's outdated and what's not.
1:08:53 No, I'd also add to that that the security posture of an organization is different than the security posture of an individual.
1:08:59 And from organization to organization, that's also different.
1:09:03 So I don't really think about it as how is Workbrew more secure than Homebrew.
1:09:07 It's when you use Homebrew at work, how are the security needs different than they are for an individual user?
1:09:13 And how can we make sure that we're serving them correctly?
1:09:16 And depending on the organization, that posture can look very different.
1:09:20 So I talked to some companies where the head of security is like, we really trust our engineers.
1:09:25 We never want to be blocking for them.
1:09:27 We give them root access on their machines.
1:09:29 We teach them how to do things in a secure way and we rely on them to report and have auditing and things like that.
1:09:35 And then there are other places maybe in a highly regulated industry.
1:09:38 Let's say, for example, a financial institution where they, by regulation, cannot just give the keys to the castle to their developers.
1:09:47 Things have to be super tight and locked down.
1:09:49 And so our position is to make those different security postures viable depending on what the organization needs.
1:09:57 And most of those challenges arise not just out of using Homebrew, but using Homebrew across many endpoints at the same time and having to have compliance and security across all of the endpoints.
1:10:09 Having one machine that's got three pieces of vulnerable software is one thing, but having a thousand machines where only one of them has three pieces of software that are vulnerable is a whole different story from a risk perspective.
1:10:24 And having that visibility over the machines to not just assume everybody is at the same degree of vulnerability and to be able to then make decisions on how much effort are we going to put in?
1:10:38 Is this something where we need to spin up a task force to track and resolve this?
1:10:43 Or do we just need to send someone a Slack message and say, can you please connect your machine to the internet so we can actually make sure it's up to date?
1:10:53 And, oh, that's right.
1:10:55 That person's actually on leave and their machine's off in a cupboard.
1:10:58 So that's the mitigation of the risk.
1:11:02 So we're going to be able to know what's going on there.
1:11:05 Another mitigation, I guess, is integration with MDM or other DevSecOps, DevOps, InfoSec, whatever other acronym or shortened term we can insert here for all the people who love those.
1:11:22 But working with MDM providers, I would say, is part of that.
1:11:25 So if the world is just an endpoint with a whole bunch of more JSON or XML away, how are you all thinking about working with MDM providers or any of those other types of tools that we mentioned?
1:11:40 Yeah, so we're building the workflow console, particularly to be kind of pretty tightly integrated with MDM providers and SSO providers as well, because that's obviously the two seem to go hand in hand at this point.
1:11:55 In terms of specific companies, I don't want to mention who we're picking first.
1:12:02 But essentially, if you were to list the top five MDM providers, we're actively building for one or two of them right now.
1:12:09 And we essentially will, within the year, I would imagine, build support for essentially everyone.
1:12:15 But yeah, again, this is what we're actively kind of working with our design partners are like early private beta customers on is we're prioritizing the MDM solutions that they use.
1:12:27 And if you're chomping at the bit to get involved with Homebrew and you really, really want to see your MDM solution built sooner rather than later, then that would be a good reason for you to reach out to us.
1:12:38 And we will do that.
1:12:40 Yeah, and I think that the strategy here is that as a company, we know that there are a lot of different tools that the different personas involved in this space are using.
1:12:53 And to start, our main area of focus is eliminating the needs to do custom things for Homebrew across your fleet.
1:13:03 So that might be you have a vulnerability scanner.
1:13:06 How do you make sure that vulnerability scanner is scanning all the packages installed by Homebrew?
1:13:09 Well, use Workbrew.
1:13:11 You have an MDM tool that you use for zero-touch deployment and you want to deploy Homebrew and that doesn't work? Use Workbrew.
1:13:17 You know, you have some kind of engineering productivity tool that helps engineers get up to speed faster.
1:13:25 Like we want to integrate with that with Workbrew, right?
1:13:29 Like every different, you know, touch point in the organization, we want to make sure that there's an easy story for, you know, how to make your life easier without having to write your own glue code, without having to, you know, go and depend on some gist that someone else put together and it just works.
1:13:43 So something that's, you know, my brain started spinning around thinking of all the possibilities here and usually when we're trying to build automation and build security and consistency, I like to put myself in the hands of the user and go, all right, well, what's the user going to try and do here that may break this?
1:14:01 So one of the things that came to mind is what happens if you're running Workbrew and you've got an engineer that's got, you know, the ability to install software and they go and install Homebrew on their machine?
1:14:13 What happens if you try and run the two of them together?
1:14:15 Well, so essentially the two of them are run together right now.
1:14:19 That's, I guess there's two parts to this.
1:14:21 So one is if Workbrew uses Homebrew in the default location.
1:14:26 So Homebrew essentially insists on being owned by your typically like your kind of admin user on the machine that's running.
1:14:36 So mic user on my machine.
1:14:38 So essentially the only difference in Workbrew land is that there's still Homebrew, the open source project, but it's now owned by the Workbrew user instead of the mic user.
1:14:47 And then when I run brew, it's running Workbrew, which then just passes through to that Workbrew user essentially like and nicely handles all the permissions there.
1:14:57 But the other part of that, I guess, with what you mentioned is, well, what if, because you can technically install Homebrew anywhere.
1:15:05 So what if that user was to go and install some random version of Homebrew somewhere random on their machine?
1:15:11 So that's something, again, that we've kind of built into Homebrew.
1:15:15 It's kind of not really enforceable in Homebrew without Workbrew, but we now have the ability to kind of set some of these policies at like a system wide level.
1:15:23 So if you install any Homebrew anywhere in the system, you can set this policy and effectively restrict any Homebrew installation that any user has installed and not just a one specific installation that the user has manually configured as per your organization readme or whatever, like we might have mentioned earlier.
1:15:44 It's like you've come across this problem before.
1:15:47 So a related question that I've heard people ask is the other way around.
1:15:51 What happens if you install Workbrew, but they already have Homebrew installed?
1:15:54 So we often talk about this idea of like zero touch deployment and provisioning the machines.
1:15:58 But also you have, you know, 1500 machines out in production right now with Homebrew installed on them, and each one of them has 100 packages installed via Homebrew.
1:16:06 What happens when you do the deployment?
1:16:07 Well, what's great about it is with the Workbrew installer, it effectively just upgrades their permissions to the point where it's under a Workbrew user, but all of their installed packages continue to work.
1:16:16 All of their installed, like it's as if it had been Workbrew from day one.
1:16:21 Awesome.
1:16:22 No, that's, that's fantastic.
1:16:24 So let's talk about the future a little bit.
1:16:26 So since you're building on top of Homebrew and actively involved as possible, how are you thinking about the Workbrew relationship with the open source project ongoing?
1:16:35 So we basically tried to make sure that we have extremely high levels of trust for the open source project from the early stages, essentially.
1:16:47 So before we even kind of make Workbrew the company, I reached out to a bunch of Homebrew maintainers and the kind of folks on leadership there and said like, hey, we're going to tell you a bunch of stuff or we tell our potential customers, like, and we're going to trust you to like, do us the right thing and not immediately screenshot this and put this on the internet.
1:17:09 And if you do that, then we're going to be able to have a long, nice, very trustworthy relationship.
1:17:14 And so far that that approach, I think, from both sides has gone really well.
1:17:19 Like, so we, through extending that trust, and I guess through some of the people in our community seeing other projects that have not extended that trust and it's gone badly, we've kind of built a really nice culture where we are able to kind of have very frank and open discussions with the Homebrew maintainers in more private spaces,
1:17:41 because both parties can be franker in those situations.
1:17:46 But we also have a nice kind of situation now where we have people like Vanessa, who's deeply involved with Workbrew, but also has recently been elected to the Homebrew PLC.
1:17:57 So that's kind of partly an acknowledgement as well that like, there's a kind of growing relationship between these two organizations.
1:18:03 And also I think just the fairly strict separation we've gone for with the naming and stuff like that.
1:18:08 Like we're not selling Homebrew enterprise or whatever, right?
1:18:12 We're selling a separate product that is called Workbrew that is very heavily integrated with and commercializing some of the ecosystem around Homebrew, but not Homebrew itself.
1:18:24 We're not trying to take Homebrew and saying, you know, you need to pay money for this or whatever.
1:18:30 And also, I guess like our plan from day one, and I stand by this, and this is one of the reasons why I'm so excited about Workbrew is that in five or 10 years, if you've never heard of Workbrew, which if we are successful, like we would like to be, that will hopefully be unlikely.
1:18:45 But if you work in tech, you love Homebrew, you never hear of Workbrew, you will look back at like this sort of time as an inflection point in which Homebrew gets way better for everyone in the next kind of five or 10 years, right?
1:19:00 And I think that is enabled by a lot of things.
1:19:04 You mentioned the relationship with the open source project, like Homebrew has its own governance structures in place.
1:19:09 Homebrew has elections.
1:19:10 It has its own bank accounts through Open Collective.
1:19:13 It has all these kind of policies on how the project is run.
1:19:16 It has like essentially this kind of really quite mature governing nonprofit structure at this point.
1:19:23 So the nice thing about that is both parties are kind of protected through that.
1:19:27 So Workbrew has had to be set up as an external organization of its own thing because we couldn't just hijack Homebrew even though we wanted to, which we wouldn't and didn't.
1:19:39 But it also means that the open source project kind of has the ability to decide how it wants to kind of have its relationship with Workbrew and how we're going to grow that with time.
1:19:48 But essentially, like, you know, my view with this stuff is it's natural with various things where people have seen this stuff maybe go wrong in the past with open source software and companies.
1:20:00 It's natural for people to maybe be a little bit afraid or a little bit suspicious on both ends.
1:20:04 But if trust is something I believe is like earned rather than just given.
1:20:09 And I think we have earned a lot of trust from the open source community already around Homebrew.
1:20:14 And we continue to prioritize earning that trust and building that and showing that we are the best possible people to be doing this with the community and with our customers.
1:20:25 I've seen it go right plenty, especially when you have a motif.
1:20:31 Let's call it a motif.
1:20:32 I'm not sure what other better word to use where Homebrew has like this beer iconography and Workbrew has this coffee iconography.
1:20:42 I mean, you couldn't have made this up.
1:20:44 You literally did make it up.
1:20:46 But I love that kind of symmetry between this, like, coffee's for work, beers for home.
1:20:55 You know, that works very well for me in my head.
1:20:58 So you mentioned beta.
1:20:59 What can we expect from Workbrew in the coming weeks and months?
1:21:03 So I mentioned before we're in private beta right now.
1:21:08 So what essentially that means is we're working with a small group of companies we call design partners.
1:21:13 So essentially they are people who are coming on board with the expectation that Workbrew is not done yet.
1:21:19 We're not 1.0.
1:21:21 We're not public.
1:21:22 And so they're kind of working with us to provide lots of feedback for us while we build something that is more in keeping with our needs.
1:21:30 And maybe, you know, if we had a roadmap of things, if they say this thing which is on your roadmap is really, really important to us.
1:21:38 And we really want this ASAP, then we look at our roadmap and we adjust it according to their needs.
1:21:43 So if that's something that interests anyone listening to this, then please come and talk to us about that at workbrew.com/macadmins.
1:21:51 That's the best way to kind of reach out to us there.
1:21:53 But we're expecting if that, you know, if you want to kind of wait and see a little bit more, we're expecting that we will have a public beta or maybe even a full public launch at some point later in this year.
1:22:06 And you can kind of follow along.
1:22:08 We'll be kind of making sure that we kind of announce and keep people posted in our various kind of internet profiles and in the Mac admins community on Slack as well.
1:22:17 We've been kind of keeping people up to date in there because we've got a Workbrew channel in there in which people seem to be quite interested.
1:22:23 And yeah, and also if you fancy going in there at any time and just, you know, at mentioning me or John or Vanessa and asking us random questions about Workbrew, then that's a good place to do that as well.
1:22:34 Thank you all so much for coming on, talking about what you're working on, talking about private betas.
1:22:41 I'm in one right now with some software I'm working on.
1:22:43 It can be incredibly infuriating when you don't know exactly what you're allowed to say or don't want to over promise for the future or any of that.
1:22:51 So thank you so much.
1:22:53 And also thank you for the background on all the homebrew stuff and the contributions to all the homebrew stuff, because that has been incredibly useful to me over the years.
1:23:06 I mean, I went from spending sometimes a day or two to get some of these packages installed, like Libi mobile device, I think was an early one that I used homebrew and I got it done in like five minutes.
1:23:18 Like, oh, my God, I just got a whole day's worth of work done in like five minutes.
1:23:23 That's crazy.
1:23:24 So thank you for all of that.
1:23:27 We just want to say a huge thank you to all of our wonderful Patreon backers who make sure that these episodes go out every week.
1:23:35 Weldon Dodd, thank you.
1:23:36 William Smith, thank you.
1:23:37 Justin Holt, thank you.
1:23:39 Daniel McLaughlin, thank you.
1:23:41 Chad Swarthout, thank you.
1:23:42 Tim Sutton, thank you.
1:23:43 Steven Weinstein, thank you.
1:23:45 Command Control Power, thanks, guys.
1:23:47 Sebastian Nash, thank you.
1:23:50 Will O'Neill, thank you.
1:23:51 Joe Sfara, Nate Sinall, thank you.
1:23:54 Tobias Linder from AnyKey, Adam Berg, Hamlin Crewson, Stu McDonald, Jeffrey Compton, Anoush Dorville from Advisory, thank you.
1:24:02 Bill Stites, thank you.
1:24:03 Melvin Vives, thank you.
1:24:05 Mike Boylan, Rick Goody, Michael Tsai, thank you.
1:24:08 Adam Selby, Dwayne Moss, Pax, Julian Reddick, and Tim Camps.
1:24:13 Thank you all so much for your wonderful sponsorship of the Mac Admins Podcast.
1:24:20 We happen to have a bonus question.
1:24:23 So, Marcus, do you want to ask it, or do you want me?
1:24:26 Yeah, I'll ask the bonus question.
1:24:29 So, what's the silliest thing you've ever had to write a package for?
1:24:34 So, we can have some time to think.
1:24:36 But does anyone want to go first?
1:24:38 Yeah, I'll start.
1:24:40 It's a sort of slight dodge of the question in that it's technically an error message.
1:24:45 But if you type brew install updog into homebrew, then it implies error what's updog.
1:24:57 So, there's actually a specific code to handle that particular case that was reviewed and approved, I believe, by myself and some other people back in the day.
1:25:06 That's awesome.
1:25:08 And I'm guessing that got reviewed very quickly.
1:25:10 Oh, yeah.
1:25:11 That was a must-have feature.
1:25:13 Definitely a feature.
1:25:16 I don't know if it's silly, but most of the packages, like the silly packages that I've contributed, are probably against homebrew's policy.
1:25:27 Because similar to Wikipedia, I think there's a policy that says, like, on Wikipedia, don't edit your own Wikipedia page.
1:25:32 And on homebrew, it's like, don't publish your own packages.
1:25:35 So, I have, like, a handful of desktop apps that I built with Electron over the years that I've, like, sent PRs to, you know, homebrew Cask.
1:25:43 Maybe it was before Cask was merged into Brew and maybe they didn't have that policy.
1:25:47 I'm going to go with that.
1:25:48 But, yeah, I've done a handful of different desktop apps that I've written and distributed through homebrew in that way.
1:25:56 Love it.
1:25:57 And I don't think I've written a package, but I think that means Mike is going to make me in the coming days.
1:26:02 Fair enough.
1:26:03 How about you, Marcus?
1:26:05 You've got to have something good.
1:26:07 You used to.
1:26:08 Yeah.
1:26:09 Oh, no, I've done dreadful things.
1:26:11 You know, there was the silly one.
1:26:14 There was the getting, which I'm sure as people developing or working with developers, the security in air quotes software that usually slows everything down to the point where developers can't work.
1:26:27 So we decided to create a piece of software that would, which was really just a package that would massively automate that process.
1:26:34 So it was just a launch demon that shut the machine down, which gave the same experience of running those kind of security tools without having to wait for it to kernel panic and shut down.
1:26:45 I just did it straight away.
1:26:46 But the worst package I've had to write or the silliest package I've had to write because of choices that a developer made was for some USB microscope software that required licensing, despite the fact you needed this expensive microscope to be able to use the software.
1:27:06 And the developer was applying the license file in ways that I could not work out how to automate.
1:27:15 So, you know, the process we normally find where you can just, you know, dump a license file somewhere in the operating system and it will detect it or you can work out what that license file is after you manually write it and put it in there.
1:27:27 I could not work out what they were doing here.
1:27:28 And so in the end, I created a package that would open up a text file with that license key in it, open up the licensing window and a prompt to tell the user copy and paste this into there and then clean it up and walk away and solve the next problem.
1:27:47 I mean, it's a lot faster than installing Selenium and then using Selenium or something like that.
1:27:54 Exactly.
1:27:55 And the other thing that made me laugh was this was also not a license file that updated every year or anything like that.
1:28:00 So I'm guessing that school is potentially still using the package I created, which scares me on a whole other level.
1:28:08 But what about you, Charles?
1:28:10 What's the silliest thing you've written a package for?
1:28:13 Um, I would say, uh, to disable natural scrolling or to, uh, remember when Apple switched from you scroll up to you scroll down, you know, trying to mirror the way the iPhone worked.
1:28:27 Um, I, I was, uh, a Luddite, uh, and I refused to scroll the opposite direction, uh, for a few years.
1:28:38 I have since corrected the error of my voice.
1:28:42 So my friends at Apple cannot scoff at me, but I was slow to adopt the new modality.
1:28:48 So I, I literally used one of my colleagues machines last week and they had it set to the old slash incorrect way of scrolling.
1:28:59 And, and, and I judged them.
1:29:01 I judged them.
1:29:02 I judged them as a result of that.
1:29:04 Just, just turn your magic trackpad upside down and then.
1:29:09 Exactly.
1:29:10 Or if you're not using a magic trackpad, just turn the computer upside down and do it that way.
1:29:20 Love it.
1:29:21 Well, thank you so much for, for joining us here on the podcast.
1:29:25 We're, we're really, um, excited with what you're creating and can't wait to see it where it gets to and what sort of, um, things you're going to be able to do to make life a lot easier, not just for Mac admins, but for developers wanting to be able to get that functionality of homebrew in their organization.
1:29:41 So if people want to hear more about what you're doing, where can they find you on the internet?
1:29:46 The best, the best place to find us is workbrew.com.
1:29:49 And for folks listening to this podcast, head to workbrew.com slash Mac admins, where we'll have a bunch of additional information specifically for this audience.
1:29:56 Awesome.
1:29:57 And we'll put that link in the show notes.
1:29:59 Uh, thank you to our sponsors.
1:30:02 Sorry, James, I'll get you to put the latest sponsor list in here.
1:30:05 With your dulcet tones.
1:30:07 Yes.
1:30:08 Thanks to our sponsors this week.
1:30:10 That's Kanji, Collide, Sit, Nudge Security, and our awesome Patreon backers.
1:30:18 And we'll see you next time.
1:30:20 See you next time.
1:30:21 The Mac admins podcast is a production of Mac admins podcast, LLC.
1:30:29 Our producer is Tom Bridge.
1:30:31 Our sound editor and mixing engineer is James Smith.
1:30:34 Our theme music was produced by Adam Kudiga the first time he opened GarageBand.
1:30:38 Sponsorship for the Mac admins podcast is provided by the macadmins.org Slack, where you can join thousands of Mac admins in a free Slack instance.
1:30:46 Visit macadmins.org.
1:30:48 And also by Technolutionary LLC.
1:30:50 Technically, we can help.
1:30:52 For more information about this podcast and other broadcasts like it, please visit podcast.macadmins.org.
1:30:58 Since we've converted this podcast to APFS, the funny metadata joke is at the end.

Mike McQuaid

Episode 356: Workbrew