Two's Complement - make podcast

Episode Date: February 17, 2024

Matt and Ben describe how to build a developer automation interface with Make, a ubiquitous build tool that can be conveniently inflicted on other people. Ben explains a great way to test shell scripts that doesn't work. Matt deletes libbob3.so and then regrets it.

I'm Matt Godbolt. And I'm Ben Rady. And this is Two's Compliment, a programming podcast. Hey, Ben. Hey, Matt. I don't know what we're going to talk about today. I'm feeling kind of like we should record a podcast, but I've had a long day of talking to other people and I'm a bit low energy.

So let's talk about something interesting that's going to get me excited. What do you got? Long pause. What are we going to talk about well we could talk about make i love make i was very that's all very very un um unfashionable to like make but it's it's arcane it's awkward it's spiky to use um but it's good at a particular job and that is its primary job is to already be installed on any computer you might want to use that is the the primary feature that make has is that you already have it whether you want it or not very

very likely you have it i don't actually know nowadays if an ubuntu say machine comes with it but i would be i would not be surprised to find that it is already on a system even if i went for a minimum install it just it's so base um but yeah the thing i like about make is it's sort of self bootstrapping once you've got make maybe curl oh no you see now we've got two things but all right okay but with with a very minimal set of things make can build it's everything else that you need from it so maybe you don't like make you know maybe like me you like uh to use cmake and ninja and other magical clever things to build your software but make can make those things happen for you make and download the binaries and put them in a bin directory and and make sure that they appear and that is my preferred way of distributing source code for

the projects that I'm involved in and it's like I it's one of the things i covered the most is the the feedback from new members of my team or folks who are just interested in the code that i've got they say hey i just get cloned your repo and i typed make and the whole thing built just fine out of the box it i didn't have to think about anything i didn't have to install anything and i'm like yes that's how it should be that's how software should be yeah absolutely i i love make because it's a it can be used as a general purpose tree of tasks thing doer which also can be run in parallel if you like and uh with that and and as you say it's just everywhere right like you you almost certainly have it whether you know it or not and so you can get this sort of magical developer experience where you clone a repo you run make uh maybe it prints out a little help menu of targets for you, which you run make, and then you just have everything magically installed,

and it all just works. And it's like, oh, how do I run my test? Well, you write make test. Well, how do I start up the system? Well, you run make start or make run or something like that. And to be absolutely clear here, make here could be the thing that's actually doing all of the crazy dependency tracking and right and all that but it also could just be a kind of front end to a another tool that says like hey i'm just going to make

sure the environment is right to run the rest of the system so you don't have to remember which weird packages you need to install and put where and again so i guess a corollary to this is that where it is possible i personally love to have sort of hermetically sealed um dependencies like don't assume except for maybe curl because you know right or w get or whatever don't assume that somebody will install a whole bunch of random packages globally in order to support your project locally that's kind of yeah i mean we're also i should say we're all we're very lucky that the situation that we're in certainly work in our day job is that everyone has a monoculture of operating systems it's like it's a big deal when we move the company forward to a new version of the operating system and so

we kind of know everyone's on this particular version of Linux. But even in my personal life, some of the projects I've got assume some kind of Linux. And then they mostly work on that out of the gate. You know, maybe I'll say, OK, you go and get Node. You get Node. And then I'll check that it's the right version of Node. And then I'll run it. But it's still, I mean, behind the scenes, NPM is going to be doing all the package management or whatever. And all locally and hermetically.

It's not global. But make is the thing that's making sure that you have got the right version of Node and NPM and then invoking them in the right way. And then there's a user. You don't need to know that. Make run. There you go. It's running.

Make start, as you say. And I think that's, it's for somebody who doesn't quite know what's going on with the software and how to build it. It's just nice to have a convenient API. I don't know what it's not an application program it's like an application developer interface right it's an adi yeah yeah well it's it's a you know whenever you build automation like that it serves two purposes one is it just makes people's lives easier full stop it also serves as a completely authoritative and correct documentation of how the process works right right because that's the only way to do it is to run you know make tests like that's

the only way that we have to run our tests right so if you want to know how to run the tests you can read what that does and you will know for certain and you can version it with your code and change it over time and you can have pull requests where you discuss it for certain. And you can version it with your code and change it over time. And you can have pull requests where you discuss it and be like, oh, you know, maybe we should optimize it in this way or maybe we should offer this kind of flexibility for it. And it doesn't become this like,

you know, thing that you just have to know if you work on the project or, you know, living in a rotten piece of documentation somewhere that no one's updated in three years or something like that. You know, it's like, oh yeah, how do you run the test?

Well, you pull up Ben's bash history How do you run the test? Well, you, you pull up Ben's bash history and you find all the commands that he ran to do this. Right. I've worked with folks that have got their like Google doc of shared, like crib sheets of like, this is how we do that thing.

And they paste from it into their terminal. And it's, yeah, it's not something I enjoy. And it's not something I would like to have in my project. And I guess one of the solutions to the hermetic makefile thing that people go for is is something like docker where the steps to get the environment set up are part of the docker container and i guess that's

arguably far more hermetic than the stuff that i'm talking about here because it's you know very much contained and localized there's no external state can escape into it without like a lot of work so maybe that's a slightly better thing but in my experience docker ends up being a millstone in that environment i would much rather kind of rely on well everything's in a dot bin directory inside my you know git ignore dot bin directory and that's what the make file the first thing to make file does is put that dot bin directory at the front of the path and now it's like, hey, anything we need should be in here. That kind of thing. Yeah.

Yeah. I found myself, especially in recent years, leaning much more toward projects that offer a sort of single binary download for their tools. You know, a lot of the HashiCorp tools have this. And there are other projects as well where you know you can just go fetch this thing unpack it for whatever architecture it is that you're using and there you go you've got your single binary that you could run and that factors nicely into this sort of make file thing where you're like okay if dot bin slash terraform doesn't exist then this is how to get dot bin slash terraform curl the hashicorp endpoint endpoint and then pipe it through gunzip and then chmod it and put it in

dot bin and then we're done and you're like there you go all right now anything that needs terraform will run that version of terraform and it came down and then maybe you put the the version number in there as well so that you can bump the version and like you just automatically downloads the next version and everyone's on the same version of terraform all that kind of good stuff right right right and yeah and this all gets back to make because what is make good at but it's like make this file exist right well how do i make that file exist well here's the target that describes how you bring that file into existence at this location that you want it to be and that can be a dependency of another thing that needs that file and that's just essentially what you're doing when you're

when you're you know it's like compilation is in this context is just turning curl into bits on your disk right instead of like compiling a file into bits on your disk but it's all sort of the same thing in a way yes um it's it's it's funny and i actually so this is uh something that i've been struggling with for the last week or so actually because i had an engineer on my team conduct a little experiment with his M2 Mac. Because right now, all their development, like you say, is on Linux. We use Mac as sort of a dumb terminal for a lot of the things that we do, which is a little bit of a shame. They are pretty powerful machines, but that's just how they're set up.

All of our CI runs on Linux, all of the servers that we do run on Linux, everything else. But just out of curiosity, and maybe I shouldn't have asked this question, I had him go and run our tests on his Mac. And they ran in

half the time. And I'm like, well, we're moving to Macs. On a laptop M2, the tests run faster than on our big, beefy servers that we connect to. Yes. Holy smoke. Like, a lot faster. And so, you know, this project is in Java.ava right and so moving it to a mac is not a

totally insane idea right but one of the things that i will definitely have to uh reconcile if we're going to do that is the sort of you know new bsd mismatch that you get when you have shell scripts or other things that are written for linux and now you're trying to run them on a mac and you know grep is not quite the same or some other thing is not quite the same and now i have to do this and i'm trying to figure out like okay there's no way i'm giving up on this level of automation that we've talked about right like if the choice is move to max and then do everything manually or stay on linux we're going to stay on linux yeah there's no question yeah right um but one of the things

can definitely happen when you do this kind of stuff is that you you start to accumulate these like automate these things that you build right right? Make targets that you build, scripts that you write. And you use them a few times and maybe they're useful. And then you maybe never use them again. And they just sort of hang around. And I think unlike source code, where you're maybe more frequently looking at it and you're sort of thinking about like,

okay, can this be used? Well, I've got my main function or something. And it's like, well, if it's not a dependent of that in some way, well, then why do we even have this code? Right. Whereas with, you know, some of those little utility things, you maybe don't notice that or don't think to ask that question. So I'm kind of hoping to think about this as like, okay, well, if we're going to move over to, you know, OS 10 as our main development environment, that going to force me to re-evaluate the worth of every single one of these little utilities

and things that I built. Because now there's a double cost to it. There may already be a cost because if you went back to it right now, it may have rotted in some small way, but it should be within spitting distance of working. Whereas there's sort of an unbounded amount of difference between the version, as you say, of grep

or some command line flag that you're like, there is no equivalent on bsd oh what oh what are we going to do here yeah and maybe the answer is you just delete it because you haven't used it in six months and if you need it again well you the code's not going anywhere yeah you can go find it you can dust it off spoken of this before the immutability of like the history of source code it's there to go and find again. Exactly. Is that an argument for those funny little tasks leaning even more into the make is purely a thing doer and say the things that it does are very, very, very limited. They're restricted to running things like Python scripts

for which we know are maybe more portable maybe i'm saying that out loud now but now i'm not so sure because i remember having this debate with java um and uh another colleague of ours a way back wanted to do a similar thing with java when when we were working on the system um around the time actually when we were discussing whether it was c++ or java which i think was a long while ago but um that was yeah yeah anyway that time and the sort of he was making the same point you know like i would love to be able to run this on my um on a mac or just a not my uh my desktop machine and java gives me that illusion and i'm like that's fine but the day you come to me with a bug that's like oh this weird

native library that we're using doesn't work the same way on mac as it does on linux is the day you come to me with a bug that's like, oh, this weird native library that we're using doesn't work the same way on Mac as it does on Linux is the day I say stop doing that. Because, you know, with the particular project we were talking about, that might have been a real possibility. Some esoteric networking thing or some, you know, pub sub mechanism that was like had a native backend, that kind of feel. Whereas I think the stuff you're talking about is more like AWS interaction, which seems like it might be the same across the the two and the libraries and things right so you know that's a there's a little bit of i mean i suppose i took the other side of what you're saying which is like you know like well no i guess it's not actually you said if there was a choice between okay we can't do this because sorry we have to do this manually or we leak we have automation in linux you say well we just have

the linux we can't do it on the mac but if you can get it to work um on the on the mac then you would now that makes that makes sense but yeah it's that thing of like not knowing where the sort of cross-platform troubles lie until you run everything i mean i know this is gonna sound weird but what if you had tests well yeah so i mean you know we started out this episode this episode with a with a darth of ideas yeah and now i'm looking at the clock going be like if i start talking about this we're gonna run out of time but um i think we're good but uh yeah so i mean i i have definitely done things in the past where i had a lot of shell scripts that i needed to test i wound up testing them and then what i thought was a fairly novel way um if i remember what the way that you were

tested might actually not solve the problem that we are seeing here no it wouldn't right do you want to talk a little bit about let's segue briefly into your your your way of testing shell scripts yeah and then we can talk about why it's a great idea but it doesn't work it doesn't solve this problem right yeah exactly so the the way that i did this was and i know that there are testing libraries for bash that exists like actual regular testing things yes the work the way you want to write a yes like a regular unit style test for bash you can absolutely do that um i've tried those things you know i find them kind of unrewarding like i don't really see the productivity gains that i get with other approaches to testing when i test

bash that way um and maybe it's just that i don't know how to use them effectively right that may be in my experience maybe you shouldn't be writing that complicated stuff in bash in the first place which is a kind of the argument about the python thing we just talked about but let's assume that you've got enough little bits and pieces that are like nothing more than grep and tail and a few other bits and pieces like and it's like well why would i this is perfect yeah sorry i keep interrupting you no no it's good well well, why would I, this is perfect. Sorry, I keep interrupting you. No, no. And so like the approach that I took here was to kind of treat bash as a kind of difficult to work with text-based interaction protocol. Right. So I wrote a bunch of Python that generated bash.

And I unit tested that Python. And I basically treated the Bash like, okay, this is just the protocol that you use to interact with the operating system, right? And so your tests were done at the level of the interaction with the operating system through the strings that would have been passed to the interpreter. Exactly, exactly. And so what this wound up being is you'd have a Python program that you could run and it would basically just be like, you know, run this Python program

and then pipe it into Bash because it just outputs Bash. Right. Right. And then you can unit test that Python and you could do fun things like you could just output the, write the output to shell check.

And then it'd be like kind of an almost an integration test of the Python to say like, okay then it would be like kind of almost an integration test of the Python to say like, okay, did I miss any unit tests here? Is the bash that I'm generating no good? And you could compose them together so you could have like a Python function that generated a bash function. And then you could call a bunch of those functions to generate a whole script and then pipe together different bash functions to do different things and it was kind of clever and interesting and it gave me what i wanted in terms of the confidence that i i needed to know that you were generating the right interactions with the operating system which is perfect for what you

were doing then but this what we're really talking about here is trying to develop confidence that the interactions with the operating system are in fact the correct interactions and have the same effect in both operating systems. And that's almost an integration test, definitionally. Yes. I mean, I can't even, and there might even be differences in the behavior that would otherwise be acceptable. And it would be very difficult to know what those were a priori. Right. And say, and it wouldn't even necessarily make sense to do that it's like

you know if you're in a world where it's like yeah we just deploy on linux and develop on linux why would i do anything that supported bsd that wouldn't make sense so you wouldn't design it that way yeah right so you know like i probably the real answer to this um and i thought about this too, is don't try to like, you know, lock yourself in a room with some, you know, box of pizza and a laptop and just hack this out. And all right,

this is going to be the weekend when you guys come in on Monday morning, we're going to be on Macs and right now we're on Linux. The way to do this, especially because the project is in Java, is to try to move more of those operational

tasks into the Java world. And then when you have shrunk it down to a level where you're like, okay, it is just make and a couple of other little rappery things. And I can very quickly verify, you know, I can clone, I can do exactly what we talked about a few minutes ago, which is I can clone the project, I can type make, and it'll run. And if it works if it works it works and if it doesn't well then okay try again right but this is like you're moving the functionality out of the out of the bash and into the rest of your framework you're treating it as a first class citizen inside the rest of the the code base where you know you have your libraries for interacting with files and logs and things that you already have and instead of using grep you're're like, well, okay,

I guess I will just use a regular expression. I mean, seems to make sense to me. And yeah, if you already have that infrastructure around and you don't need it to work outside of that infrastructure, makes a lot of sense, right? If it's involved in the build of that stuff, obviously you've got a bit of a chicken and egg situation if these little tools are involved in it but i think that's that's not likely to be a problem um you know and you mentioned again like the hashicorp style of of

like having these little executable binaries that are like them themselves for external dependencies we've done that in a couple of places on our projects we've got a couple of like helper binaries that would have potentially started out as python programs themselves which then entail all of the fun and games of like well how do i make this an executable and there are ways and means of turning a python function or python command line tool and its dependence and all of the and the interpreter and everything into what looks like a binary except it's just a giant tarball that unpacks itself into temp and then run. It's all,

all the bad things you might imagine that happen. It's clever and it works, but it's not great. We rewrote that in, in rust as an example of, uh, you know, relatively,

we wanted to learn some rust anyway, and we did it as, as, as a rust project. And rust is relatively straightforward to then do a static compile. And we ended up with just a little binary. then we're like okay well we version that we chuck that somewhere and that's one of the things we curl down in our make file and okay it's divorced and it's separate from our our project but if it's part of the build itself or it's

useful to work even when you've kind of broken your project and you can't do anything but you want to be able to like go help i'm debugging and diagnosing something and the last thing i want to do is have to rebuild everything then it's a convenient little way of achieving that so i've just gone around in a big circle there you mentioned like taking a long time to talk but um yeah no i you know it's it it's funny that like i don't really hear people talking about this as much as I would expect. The sort of, like, deployment impacts and the automation impacts, the decisions that you make when you're building these tools, especially tools that you intend for someone else to be used. Like, I always cringe a little bit when it's like, oh, here's this great tool that does this thing. How do I run it?

Well, you get this Docker image and you run the Docker image again i will did you really not have done better than that you know i don't you know my feelings on docker i've made them uh clear here as well that is one of the few uses of docker that is maybe okay for like certainly for ci it's like we are in a very stable world now where i just know that only the things that i said i needed are there and that makes sense but i don't see it as a great developer experience i want it to work as a developer i don't want to have to work in a pretend copy of my own machine inside my own machine you know there's sort of a russian doll thing going on here and then there's the the issue that like essentially by running docker you have root on the system that you're running on whether you

want it or not and every every file's owned by root. And you want to punch files in and out, and then you'll write. It's just all there for developing. And I know that there are ways and means of making it slightly better, but it just feels like, I don't know, you've seen the meme. It works on my computer. Well, we'll ship your computer then, and thus Docker was born. And it feels a bit like that. It's like, well, the build works on my machine.

All right, well, let's tarball up your machine. now barry's machine dot tar dot gz is how everyone builds software it's like how is this built uh i don't know now obviously docker definitely has much more of a flavor if we know how it was built although there's a whole other conversation about like how easy it is to make a docker image that isn't reproducible because the very first thing you do is like sudo apt get install these things you're like oh which version of those things did it install i don't know the ones that were around when i ran the image at that time yes i know that is yeah reproducibility is difficult um yeah but uh i've lost i've completely lost the thread of where we were going with that now because i got ranting about docker as is my way that's but i said yeah you were saying about like

um other people if you pull down someone else's repository and they either have a docker file or for me the worst thing is it says first of all sudo apt-get and it lists this gigantic list of dependencies i'm like i don't want to install these on my computer. I already have an incompatible version of this thing. And I don't want to install your version of it over the top of mine. Yes. I mean, honestly, it's sort of like whenever I see that, it's like going into a store and they've got like i don't know pants that someone else has tried on right like it's like like you know i realize that they're they're not like cleaning them and they

just fold them and they put them back on the shelf and it's like this is how clothing stores work but it's just like i don't want to pollute my environment with whatever random packages and i won't know why you know later on when i run out of disk space or whatever i'm like why have i got lib bob 3. this what the heck is that and you uninstall it and you're like well and then i hope something you know nothing goes wrong and then later when you run some random tool it's like unable to find lib bob 3.so and you're like oh I guess it was for this oh yeah I can't blame it because software I mean certainly

in the native world software deployment and software configuration for c and c plus plus is not good right if you depend on something then really yeah you've got two choices either you ship it yourself

or maybe you say you skit submodulate in maybe and then you say oh yeah now you must you know configure an autoconf and all that horrible ridiculousness to build some random library or you tell somebody oh yeah sudo apt install this thing oh and if you can't get hold of it here's some random d package um uh repository you can add to your app list and then i don't know some random person on the internet's putting binaries on your computer you know i don't know sure fine whatever whatever went wrong with sudo apt installing someone else's code um but yeah it's not easy to solve i know there are package managers that make this a bit easier. So some of my projects have used Conan

and there's VC package as well. But the thing about both those things are certainly Conan is written in Python and has its whole ecosystem. And the cool thing about Conan is I can install it with Make. Yeah, yeah. And then I'm off to the races.

Now I'm like, hey, no one need know that I'm using conan because you download my source code you type make and behind the scenes conan goes and solves dependencies downloads the rest of it and we're back to where we started in this whole conversation which is like it shouldn't matter what it is but make starts it off yeah and like you know there's there's definitely like the sort of's definitely the user space versus root access type considerations there. At some point, something's going to have to depend on some library, and I hope that the architecture of the system is enough to give you that information you don't need to you know have like like there's a decision to be made and this is like a software design decision where it's like we could do this cool thing

but then every developer that every works that ever works on this project is going to have to have this thing installed as root because there's no other way to do it and it's like you know i'm not i wish i could say that you should just never do that. Like, that's just unfortunately not true. But you should not weigh those decisions lightly. You should think about what the long-term impacts of all of those things are going to be. Because it's just a tax that you're going to have to pay forever. You're never going to unwind that, right?

Unless you, like, move from Linux to Mac and you're like, ah, maybe we can't you're never gonna unwind that right unless you like move from linux to mac and you're like ah maybe we don't need yeah right and then you're like deleting large amounts who uses make you know test three or whatever make make uh uh log tail you're like well it's got some complicated tail minus f thing in it but you know you know what also is good at doing that i can write 10 lines lines of Java that will do the same thing. Yeah, yeah, yeah. Write once, run anywhere as Java is. It tries to be. One thing, actually, one thing I've never done that I might wind up doing as a result of this

is these days, I'm pretty sure that it is possible to write a Java file with a shebang at the top and then just run it yeah um and i had never really had the opportunity to do that interesting because the most of the time if i'm doing something like that i'm reaching for bash uh or something like that but it it would be interesting if some of these bash scripts that i have actually turn into java they can use some of the other tools that we have actually turn into Java. They can use some of the other tools that we have in the project. They could be unit tested in the same way

that everything else can. But you sort of use them as you would use a bash script. They're command line friendly. You can pipe the output to places. Frankly, even if you can't do it with a shebang directly as Java, you could very easily make that generic Java shim app that just runs itself as argv0 but with inside you know that dot jar in some internal directory or more importantly does make java hyphen compile

and then does that thing so that you're always making sure you're running the most up-to-date version of that and not being confused um that's an that's an interesting thought. Yeah. Well, yeah, it's like an option to Java C where you can say I'm going to give you a.java file. I want you to compile it and run it in a single operation. Right. And so you put that in your shebang

and now you can just kind of write Java like you would any other interpreted language. Right. But, you know, I've never actually done it right i'll be i've interested to see how you get on because uh certainly one thing that i have noticed with uh the compiler explorer startup time is that one of the things we have done or sometimes do is run every compiler that we have um at startup with just dash dash version just to say what version will help and we do some primitive parsing we do actually do this

offline now we but because of this reason um some of the compilers that we support are written in java like for example the java compiler and the Kotlin compiler and the whatever, what's the JetBrains, no, that is JetBrains, Scala compilers, all these kind of things. And one of the more recent, I don't actually know if it caused an outage, now I say this out loud, but certainly the cause for my phone going,

catching fire with alerts about telling me about failed instances was we hit some kind of threshold where there were you know we in order to start up we run like four or five of these at once right because you know you it's it's node it's really easy to do it's acing but um we didn't have enough ram to run eight or nine copies of the jvm each of which thought that they were the only jvm on the system and so the thing kept booming and was being killed and then the whole node would be killed and i'd get an alert and another one start up and would die again and you're like oh oh no so there is a this is obviously this is just my opportunity to kick kick java a little bit which i give people grief about for doing and

now i'm just doing it now i don't i do why do you need 100 megs of memory to tell me what version you are yeah guys yeah and i mean of course i i'm very much aware why because it's a much more sophisticated system than than all that but uh it does still um great a little bit when you're like running four copies of it you're like what 150 terabytes of ram all right maybe not that that's a bit except even for like our beefy work machines 150 terabytes of ram would might be a lot of ram i want a computer with 100 yeah that'd be pretty cool you know that sounds really how much what's the maximum what's the largest amount of ram you've ever had in a computer a million a million that's the largest number isn't it i thought it

was the largest number i don't even know how much ram my i'm just gonna run that now it's like one of those things where i've stopped thinking about it for the most part i know that like some of our production machines have 512 gig which is like mind-bogglingly large uh that's half a terabyte right you know that already is like i've i don't know if i have that much oh i do have a drive downstairs in the basement that has like my videos and stuff on it that that is bigger than that but like most ram sorry hard disks i have are not that big yeah uh at prev prevco we had a database instance that had 192 gigs in it and i think that's probably the most that i can remember i'm now just running on this oh i don't know how to use a mac i've got a mac now i know we talked about this the other day

and the fact that i've finally accepted my fate that the company wants me to have a mac and and all those things i don't know how to find out how much memory it's got i've just typed free this is exactly what we're talking about right yeah right df worked for me to say how much hard drive space i've got and then i did three dash tools are like the bizarro world of gnu right yeah what is everything is kind of the same but not really the same just typed memory it's like solaris did you ever you ever work on solaris at all uh yes briefly and erics was the other one i worked on which was the uh sgi one i think uh these were all uh back in the day i think we've talked maybe have we talked about my multi-user dungeon thing i think we might have done at some point but i was running certainly

in the notes that when we were looking before this uh for an idea about what the heck we were going to talk about there's some notes that we should talk about it some more but um for a long while uh my multi-user dungeon ran on a borrowed and the listener will have to imagine me doing air quotes about the borrowing and the legality therein of a unix account on a machine that was an erics machine so i had to learn how to administrate enough of erics to be able to run my my mud on it But yeah, these things, again, it's funny. There's kind of like an uncanny valley of like, if I'm on a Windows machine, there's no question in my mind I'm not going to try and press the keyboard shortcuts

that do the things I'm expecting. But a Mac looks just enough or feels just enough like a Linux machine that I'm pressing buttons and then I look like my poor old dad trying to use a computer that i'm pressing buttons and then i look like my poor old dad trying to use a computer i'm like pressing buttons windows are popping up and disappearing i'm like oh where did it go where's it gone yes uh where and then like yesterday i was on a call and i moved the window off the side of my monitor to the other monitor and it and then i couldn't find it again and i'm literally on a call with someone trying to debug

something i'm like you're gonna have to excuse me i'm gonna quit and restart the program i'm like oh no this is the beginning of the end anyway that's very much like make in summary oh dear i feel like we can't really finish on any other point now unless you had anything else god if whatever is there anything else you got for me or have i just destroyed you what what have we what have we learned today what make is a great application um developer interface like if you adi of like you should be at a cloner project and type make build or make or whatever it is you do and then you've kind of got something which any developer in your organization or your friendship group or your listenership who can go hey i know how to build your software you're like great um we've learned that max and linux machines are

different same same but different yes deceptively so and i that we know we learned that Matt doesn't know how much memory his computer has anymore what else would our listeners need to know out of this this is what they come for this deep insight yeah if you're building a tool

that you want other people to use please give me a single binary for it because I'll love you if you do uh yeah that's a good one uh you know docker sucks that's good well you heard heard it here first everybody docker i use docker every day i know yeah it's it definitely has its place we've we've said that before it's like you know i think the bjornis drewstrup has a quote about programming languages which i think adequately also applies to a lot of things, including tools like Docker. And that is, there are two types of programming language in the world,

ones that people complain about and ones that people don't use. Yeah. And I think that's true. The only reason we complain about Docker so much is actually it's pretty useful. Yeah, true facts. All right, my friend. I think we should call it there. Somehow, we've talked for half an hour on absolutely nothing.

Right. Maybe to ourselves, because maybe we lost our poor listener along the way. Probably so. Statistically likely. It is. It's true, yeah. Alright, my friend. Well, until next time. Until next time.

You've been listening to Two's Compliment, a programming podcast by Ben Rady and Matt Godboll. Find the show transcripts and notes at www.twoscompliment.org. Contact us on Mastodon. We are at twoscompliment at hackyderm.io. Our theme music is by Inverse Phase. Find out more at inversephase.com.