The Changelog: Software Development, Open Source - Ruby Tooling, chruby, ruby-install, Security (Interview)

Episode Date: May 2, 2014

Adam and Andrew talked to Postmodern about his open source projects chruby, ruby-install, chgems, ronin, and more.

welcome back everyone this is the change log where remember supportive blog podcast and weekly email covering what's fresh and what's new in open source check out the blog at the changelog.com our past shows at five by five dot tv slash.tv. And you're listening to episode 120. Andrew and I talk to Postmodern about his open source projects, CHRuby, Ruby Install, CHGems, Ronin, and more. Today's show is sponsored by Ninefold, CodeShip, and New Relic. We'll tell you a bit more about CodeShip and New Relic later in the show, but Ninefold is our first sponsor.

They're a high-performance platform for deploying and hosting Ruby on Rails applications. The platform is built on Ninefold's own infrastructure with servers in the U.S. and Asia Pacific. Because Ninefold owns the entire stack from the hardware up, they provide you with quantifiably superior performance compared to the competition with more economical scaling. Ninefold makes it extremely easy to deploy your Rails application straight from your Git repo by either using the online wizard or the command line interface. Ninefold also offers great support, zero downtime deployment, SSL, Redis, memcache, load balancers, and firewalls for free straight out of the box. Experience Ninefold's superior performance and easy deployment with a 30-day free trial. Just visit 9fold.com to sign up.

And now, on to the show. Welcome back, everybody. We are joined today by Postmodern to talk about CH Ruby or Truby. Not really sure the correct pronunciation there. We'll let Postmodern give us the definitive answer at some point. Ronin, CH Gems, and a number of other projects that Postmodern has been working on. So to get started here, why don't you give us an introduction of kind of who you are and where you come from and projects that you're working on? Hello, I'm Postmodern. I write a lot of Ruby by trade. Kind of CHRuby and RubyInstall were kind of more recent projects I wrote just out of sheer need of them. So it's not like a real passionate kind of backgrounds.

Yeah, so I hail from the Pacific Northwest or Cascadia, as we like to call it. Got some friends there. Yep, yep. It's up in a little teeny town, Portland, and kind of native for a long time. But yeah, so mostly I do a lot of security research. I like developing tools and kind of automated attacks. That's really what I'm into. It tickles my fancy. And as I kind of got more into using ruby forts i kind of like got into noticing the pain points and i thought well

you know i've i've been working in ruby for a long time you know maybe i could try my hand at actually you know fixing some of these or making tools that uh kind of like fit met my needs or you know solve my problems so that's uh that's kind of fit met my needs or, you know, solve my problems. So that's, that's kind of what I've been doing. And, you know, yeah. Gotcha. So real quick, just to just to kind of get a get an answer here. I've always called it ch root, but I could be wrong. You're the security person. So give us a what do you call it? You call it ch root? And then subsequently, do you call it chruby? Or what should we be calling it? Man, so I think it really depends on the people or the persons.

Everyone has their own weird pronunciation of all these Unix utilities. Because they were designed to be easy to type out, not really necessarily pronounce. And so I've heard chroot, I've heard, uh, cheroots, I have heard cheroots. Um, there are people actually like, I don't know, maybe once I've heard someone say like change roots, actually like spell out the actual word. So I really don't know. Um, I don't know what the actual pronunciation is. And I think it's more just like, we, it's not really necessary to actually say it out loud cause we just type it. So it's kind of like we it's not really necessary to actually say it out loud because we just type it so it's kind of like one of those things you're just like you know that

thing yeah that thing yeah yeah yeah yeah i think i uh i'll stick with ch ruby then uh and whatever tickles your fancy i guess is the appropriate answer here in the pre-show you mentioned a funny one what was the funny one that uh for linux that that uh could be said kind of a funny one that uh for linux that that could be said kind of a funny way oh well um i don't know like it's kind of a weird thing like a lot of talking a lot of people everyone has their own pronunciations but um one of my friends was actually a while back doing research into using uh the upa np protocol or universal plug and play protocol which allows you know routers to open up ports uh for services and stuff like that, port forwarding. But you can actually use it for punching holes in firewalls on shitty NECA routers.

But he kept referring to the protocol as up and up. And so he's like, yeah, I'm looking into this up and up protocol. I'm like, what is that? Well, up and up is the protocol that lets you open up ports. Right? It's on the up and up. Yeah. No, that's awesome. So why don't you, just for everybody that, I don't know, if you work in Ruby and a lot of our listeners do, I'm sure they've heard of RVM or RBM or CHRB or whatever.

So why don't you kind of give us an introduction to just what is CHRB? What's the reason that it's here? Okay. What is chRuby? What's the reason that it's here? Okay, so before chRuby, I actually used RVM a lot. And I used it primarily on Fedora. That's kind of like my main operating system of choice. Before that, basically, I kind of only used actual system Ruby. Because before that, I was of only used actual system Ruby because before that I was on Gen 2. And actually, no, so kind of a side note is

Fedora actually does a really good job of packaging Ruby and they actually configure it. They configure Ruby gems to install into your local home directory for gems when you're actually a normal user. And when you're root, it installs into USR, local share, wherever. So it really wasn't necessary to use RVM a lot because a lot of times I was just using the most recent version of Ruby. But, you know, when I actually needed to upgrade and test newer versions of 1.9 and 2.0, then I kind of like, OK actually started using uh rvm and it was recommended to a lot of my other

friends where I try and get up to speed and ruby and so they could help out with like open source projects and collaborate together but anyways um one of the problems there's like a lot of the pain points that developed along with using the rvm extensively for a long time and one of the kind of the main ones is like yeah it's a huge collection of bash scripts and bash is kind of a really terrible programming language and environments and that kind of contributes to the bugs and there's also platform specific issues where certain platforms will change things and it has to be cognizant of all of this. And then there's also issues with how it organizes rubies. Like, for instance, you basically assume that it should be installed into your home directory.

You can install it system-wide, but the installation of the software is coupled to the location where it actually installs the rubies. And that really kind of annoyed me because I really kind of wanted all my rubies out of my home directory. I wanted my own software installed globally so other users on my system maybe like I have some automated scripts that ran under like a you know dummy user account for safety reasons I wanted it to have access to it and I want to have rubies installed in some global location and then also have rubies installed in some like you know my home directory or you, I have other partitions where I usually just, like, a dump code where I want to, like, check out the latest version of Rubinius, and so I'll pull that down in some other directory and build it there.

And that really wasn't possible with RVM. It will be possible with RVM2, the ability to mount arbitrary installation paths where Ruby is installed, maybe you threw it in the opt directory or somewhere else. So that was kind of one of the things. And then eventually, I just got so many bugs where I kind of went back to using System Ruby because it was just really useful. And most of my work involved just just developing against like you know 2.0 right and then using travis ci to test all the other versions right but then um i got like started a contract and i was like oh crap i'm gonna really need to get a working environment here that i can just you know use any sort of version so i kind of got thinking about it and it's like you know

usually when i start projects there's always this period of like deep thought and kind of research so i was kind of like do i really want to spend the time developing like a ruby switcher i mean there's rvm it's giant am i gonna like fall down the same path that um you know kind of like the the developers of rvm have like uh i believe uh believe Wayne kind of got burnt out with dealing with all the issues. And Michael Pappas is, or Mikkel Pappas is doing a really good job of maintaining it, but still, like, really stressful. So I was like, I went around and kind of, like, researched how RVM basically, like, changed, manipulated the path. And then I also got, i looked at rbm as i started like okay well let's let's look at the alternatives before i jump into like starting a huge project right before

a contract job where i'm gonna have to be like heads down dedicated and so there's like lots of various other ruby switchers out there and um rbm is pretty much the only shims based Ruby switcher. And so there's kind of like issues when, uh, cause I tried it when it was still kind of pretty new and fresh. And so, and it was kind of confused with how the shims worked and there's, they had like different levels of setting, which desired Ruby do you want? Like, uh, you had like the, was it shell local system and global or something like that? Yeah. And then also I've, I felt like it, it copied a lot of features, not copied, but you know, it re-implemented a lot of RVM ish features. So I kind of felt like it wasn't really thinking

outside the box. It wasn't like unthinking. It was still kind of following in the shadow or the footsteps of kind of like how all of us Rubyists have sort of like grew up expecting the environment to work and the tools. And, you know, like even has a subcommand feature, which is like a very RVM-ish thing, in my opinion. And instead of having multiple separate utilities and scripts that work together in conjunction, has this huge subcommand thing. But yeah, there's also lots of other weird Ruby switchers, it turns out, that I was kind of looking around. By the way, I define Ruby switcher as something that only switches the Ruby version. That seems to be the thing that you say most,

is like this is just a switcher. It doesn't install like RVM does. It's one job or one job only, which I guess falls back on your Linux Unix background too, of one job really well. Right. And there's lots of other, basically, implementations

of this. And I found that I kind of went through and kind of rated them or scored them on features. One of the, probably the most well-developed ones was uh rbfoo uh by hmans that's his github handle and so i tried that i was like okay this might be it what i'm looking for and because they just need something really minimal that just

manipulates path and you know sets some couple environment variables you know it shouldn't be this hard. And so I looked at it, and, like, some of the things were nice, but one of the things that kind of annoyed me with it was kind of the syntax. So when you actually type the version, for some reason he, like, began the versions with an at sign. And then there was also kind of the whole coupling where it expected the rubies to be in your home directory. And sure, you could probably symlink them out,

but I really wanted to have a configurable list where I just give arbitrary paths. And then also, I noticed a lot of these Ruby switchers, they would hard-code the gem path and gem home, which are kind of the locations where it should look up the Ruby gems. And one of the things that kind of annoyed me is, so when you install, since, was it Ruby 1. up the Ruby gems. And one of the things that kind of annoyed me is the, so when you install, since, was it Ruby 1.9,

Ruby gems has been shipped with Ruby. So it actually, Ruby gems has its own main gem directory inside Ruby. And actually now Ruby comes with some pre-installed gems, like Big Decimal, IO Console, and some other ones I can't remember off the top of my head. But anyways, so it's really important that, first of all, you're not supposed to assume that the gem directory that's in the main Ruby install is always in that location. Because Rubinius actually has its own also gem directory that's kind of in. When you install Rubinius, it also installs its own gem directory, and it's not in the same location, which is kind of a little annoyance.

But also the fact that you need the actual API version of the Ruby. So, for instance, this is not the actual version of the Ruby, but the actual kind of overarching API version like, you know, all the 1. So for instance, this is not the actual version of the Ruby, but the actual kind of overarching API version, like, you know, all the one eight series, it was just one eight. But since MRI one nine zero was kind of a botched release that had like some showstopper bugs in it, they actually bumped the API version to one nine one. So that's kind of another kind of like hiccup you have to detect and then also um the gem directory might not be writable um people assume it's going to be writable because the ruby install is in your home directory and you probably have a writable access to that and i kind of felt that

that was kind of violating the whole unix principle of uh keeping software separate from the user so you don't actually delete it or you know download some weird virus and you know embeds itself in the software you have writable permission separation where you you would separate the gems you installed as a user versus the gems you install as roots which is something also i i you know copied from how fedora sets theirs up and i think uh deviant also has updated has done something similar and also want to basically be able to switch between rubies from arbitrary locations and it would just automatically detect the gem directory and calculate it all out the other thing

that also annoyed me about using rvm was the fact that they made gem directories specific to each patch level which was really annoying when you upgrade because you have to upgrade your gems and like it's only a patch level guys it's not like a big feature feature breaking version release um so that's kind of like that i put all that together i think i spent about a week week and a half kind of like doing all this research and kind of like figuring out the features and how to go about doing them. And, uh, kind of wrote up my first initial version. And so, so you spent the couple of weeks trying to figure out the features and then the feature you landed on, uh, the feature set you landed on is like very, very small. It's interesting.

And just to clarify, like we've had kind of the longer this show goes on in terms of the changelog as a whole, not this particular show, we've obviously had predecessors and then current of the previous ones because what they do is they set up a path and like a you know you can learn lessons and ch ruby has in postmodern has benefited greatly from the things that the ones before him have done and so yeah go ahead also i was going to point out that uh uh mikhail pappas, the current maintainer of RVM1 and also who's working on RVM2, basically kind of showed it to him. And this was like the first version of CHRuby, which didn't even support auto switching. And he was like, oh, great, another Ruby switcher. Oh, you're going to just disparage RVM and poo-poo on it. And I was like, no, like no no no it's just completely different scale down it only does this one thing it's not supposed to try it's not trying to

compete with rvm or even rbm as far as i can tell too when michael was on the show recently too he was saying that rvm 2.0 was going to expand not only into ruby but also python and be and go beyond so i mean i think he had like this much larger scope to go towards. Yeah, he's talking about basically also integrating with the package manager. And so it's very similar to certain things like, oh, Redhead has this thing called, was it software collection layers or something like that? But basically he wants an environment manager, literally,

and something that can install MySQL and dump a really nice basic configuration so you can start using it out of the box. Yeah, and also he's helped me a lot with a lot of the bash issues and sort of bouncing ideas off him. Like, well, how did RVM handle this weird, obscure problem? That's awesome, honestly.

I mean, Michael's a good guy. I know he took over for Wayne when things kind of got harder for him and we've had uh several people on the show come in and talk about um burnout i can't recall his name andrew helped me out but he was um just like four or five shows back names gap me right now i have to look at our show list but i think to andrew's point was to say to say that we're not here to bash any predecessors. We're here to – this is open source. Things change. Software is the most complex, volatile market ever.

So, I mean, obviously that's the case. We love Mike. We love RVM. But we lift up everybody to kind of get their word out on what they're doing and why it's important and why Ruby should care. Yeah, yeah, definitely. Let's pause this show for just a minute and give a shout-out to our sponsor. to kind of get their word out and what they're doing and why it's important and why Ruby should care. Yeah. Yeah, definitely. Let's pause the show for just a minute.

Give a shout out to our sponsor code ship. They're also a partner of ours. So super excited to be working with code ship. They're a hosted continuous deployment service that just works. You can easily set up continuous integration for your application today in just a few steps and automatically deploy it when all your tests pass. CodeShip has great support for lots of languages, test frameworks, as well as notification services. They easily integrate with GitHub or Bitbucket

and can deploy to cloud services like Heroku, AWS, Nojitsu, Google App Engine, or even your own servers. Get started today with their free plan. Setup only takes three minutes head to codeship.io and also check out their blog blog.codeship.io and one more thing to mention for our members you can save between $294 and $2,994 on your first year with codeship so make sure you take advantage of that head to the the changelog.com slash benefits to learn more. Once again, CodeShip.io.

Try it today. So to kind of move forward, when I first found CHRuby, which was, I don't know, maybe 10 months ago, a year ago, 15, I don't know, somewhere in the past, the way that everyone was using it was basically using Ruby build, which was built by Sam Stevenson and others. I think originally just was supposed to be purely for RBM. And then they decided to like, make it easier to use as a

standalone thing. And so chruby was just a switcher, and a lot of people are using RubyBuild to actually install rubies. And just recently I went back and started evaluating these things again, and I saw that now there's RubyInstall, which essentially does the same thing as RubyBuild. It actually allows you to install rubies. So obviously we see why you created created ch ruby and you know

looking at all the other ones what about that why did you create ruby install so initially i also used ruby build because you know it's it was a nice decoupled tool and i could just use it for its one specific purpose but there's lots of things about it that kind of got under my skin and so i started this whole process of kind of like evaluating it and evaluating how RVM also handles compiling, installing. And of course, they go into way more detail of handling weird, obscure platform-specific issues. But so the way Ruby build works

is it has basically definitions for every single version. So literally, you have to actually specify the every single version. So literally, you can, you can, you have to actually specify the fully qualified version. And that was kind of one annoyance, because literally, I just I, when I install, you know, some version, I really don't care, just give me the most recent 193 that you know of, or, you know, literally copy and paste the version from the news, the news announcement on RubyLink when they release a new version. It's going to be there, so just copy and paste it in the command line.

But then as I kind of dug into it more, that was kind of a minor nuisance, but I dug into it a lot more. I found that it does lots of really weird things with trying to detect kind of when libraries are available, and it also can download its own versions of OpenSSL and compiles those and then links Ruby against that. And that kind of like, that worried me because I automatically knew that eventually there's going to be a vulnerability in these libraries,

and there's not going to be an easy way to update them. You can't just go like, oh, update the library. Like it's compiled, installed into its own directory, and literally you have to reinstall the Rubies to force the newer version to get downloaded and then the Ruby compiled against the newer version. So I was kind of like, well, obviously, that should be another feature,

is just to use the package manager because every system, the packages are there, available. You can compile against them. And Ruby dynamically links against them. And so when there's a vulnerability, you just update the package, you're good to go. And also distributions are really good about backporting security fixes.

And so you can update and not worry about getting weird API breakage. You literally just get that one fix. So that was kind of another thing that inspired me. And I really just want something that would work on as many systems against many package managers as possible. And, of course, it's a lot easier because chruby has to work in both bash and zsh, whereas Ruby install was a utility,

and so I could just write against bash 3 and do that yeah and so and I basically kind of took a very declarative design to it where literally you have like individual files build files for each major implementation and they define the configuration step the compile step and the install step and then kind of like any sort of specific package manager configuration like you have to do some weird things with homebrew because its packages aren't in like a place where a lot of the um the auto the autoconf scripts of m can find them. So you have to literally hint at it, which is something I learned from RVM where there's an option called withopter,

and you have to pass that in specifically for Homebrew and Mac ports also because Mac ports installs in ops. That's still around? Yeah, yeah, actually, Antz, I recently got a bug report from a user who was attempting to use Fink, which is like... Super old. Yeah.

And back in the day, actually, I had the last generation iBook, and I ran OS X for a while. And then back when it was like PowerPC, and I went back to running Linux on it. So I knew about Fink, and I was like, whoa, that's still a what? People use that still? Oh yeah, just glancing at the project homepage, they are still getting regular releases, which is pretty cool to see it

lasting this long. That's cool. I guess that's a... You had a... Not a feature request, but a bug report. You do the chruby and ruby install. They do such small things. So how often, like chruby is 90 lines of code, right?

So maintaining this seemingly would be much easier than maintaining RVM. So how much of your time do you have to dedicate to actually maintaining chruby? It's pretty much feature complete at this point. Basically, I'm sort of waiting. It's kind of one of the first projects where I've been really skeptical about feature requests. Normally, a lot of my projects, I'm like always trying to please whoever is submitting the issue and, you know, thinking up crazy new features to add this is the first one where i actually really constrained myself and that was caused primarily because the lot of the line uh line count uh limitation because i want to keep it the core of it in 100 lines and um of

course there's other additional things like the the auto switching but that's in a separate file that you can choose not to load because a lot of, on a previous job, I worked with this system administrator who just cringed at the idea of having some sort of crazy bash script that auto-detects and switches rubies when you see the interdirectories. But yeah, so that really has kind of constrained me, and that's going to be kind of really interesting where I actually really critically look at features

and whether they can be implemented by third-party tools, or do they have to be integrated, or do we even really need them? Because a lot of the feature requests were basically things that people were used to coming from RVM, and I kind of think, well, do we really need this? Or is this something we're really kind of familiar with and we miss did i miss why you said that there's a constraint why the underlying constraint so basically i wanted to keep it as small as possible i didn't want to like go out of control and you know develop a you know a sub command system or any of these other things that the bigger kind of ruby switchers managers have and so i kind of like i always kind of like look down on the whole idea of like putting line

constraints line count constraints on projects as kind of like it's kind of like a hat trick you know it's kind of like vim golf yeah but really it does it does help you it forces you it like it sets a real kind of like um like risk points or danger point where it's like you cannot pass this line that's this invisible barrier and once you do you're in some danger right and um yeah and so that that's that's going to help me um dealing with maintenance uh there was a period when i first rolled out the auto switching that i did have to deal with tons of bugs and weird shell issues and so i spent a lot of time asking stupid questions in the Bass IRC channel

and getting really kind of like burnt out, disgruntled replies. Stop asking. Yeah, I know. It's like RTFM, dude. Yeah, so that kind of did take up some time. But since it was so small, a lot of the changes just required thinking really carefully about kind of the tradeoffs. That's another thing about shell scripting is it seems simple on its face,

but every single command, every serve behavior has like a dozen or so edge cases you have to be cognizant of. And then there's also implementation differences between the shells uh based on like what's how they evolved because like bash came from ash um and there's also dash which is the bin sh on dbin systems which is like super minimal it has barely anything like most bash code will not run on it um And then ZSH actually came from KSH, and they have their own weird, bizarre features that many people probably don't know about. For instance, arrays in ZSH are indexed starting at 1, not 0.

So you can't really rely on that. Yeah, I know. They thought it was a really cool feature. That's stupid. Sorry. I know, yeah. But yeah, the kind of way you get into that, the more you have to sit there and actually test and ponder. And that's actually the other thing is I was really super aggressive

about unit testing shell scripts. And it always seems like when new languages come out that don't have test suites, or people kind of misinterpret the language or, I don't know, they think it's really simple. They always like say, oh, we don't need a test. Why would you test that? Just run it from the command line.

You don't need unit tests here. And people said this for like JavaScript when it was first starting out when like, you know, most code was just like three functions. And then they also said about Bash script. But then once the testing tools get developed and people get used to them, it really does help. And that helped kill a lot of bugs. And actually it was really cool because a lot of the other people who develop their own Ruby switchers came in and started like suggesting features and, you know, how to solve various, implement the auto-switching.

So we actually were discussing this in issues by sending, submitting pull requests, for example, unit tests. So we really were just, like, speaking, using the tests as the implementation. And so that was really cool to see. Instead of, like, you know, getting these long-winded discussions and issues, we could just be like, here's the code. Yeah, and I can imagine that looking through pull requests, kind of as an aside here, looking through pull requests and stuff for Shell can kind of be kind of a disaster, right?

Because somebody submits all this code. Yeah, you have to understand it. Everyone has their own weird styles yeah there is although um shell scripting does it's probably even more style obsessed than ruby is uh there's this one user who uh contributed came in and basically just like submit submitted this giant pull request that broke all the tests and he's basically trying to rewrite it from scratch and like it's like whoa slow down let's take this one step at a time and basically kind of like he got me to um fix all the style issues and wow like for instance there's like very hardcore these style issues are not just like you're supposed to do it because it looks nice but there's actually safety reasons behind it for instance most people when they

start doing shell script they always see uppercase variables. So they just assume all variables are uppercase. But all script local variables, all function local variables are supposed to be lowercase. So they don't overshadow the other global variables that are passed in as environment variables. Yeah, so that's kind of like one of the major things we had to change. And yeah, there's other stuff. one of the major things we had to change and yeah there's other stuff that's crazy so awesome have you had any other projects that have gotten as popular in the open source community as these geez um i'm trying to think here

maybe maybe bundler audits that's that's probably it um or actually there's another library i did where after ruby19 came out ruby zip was kind of unmaintained for a long time it didn't work and so i just got frustrated and forked it and you know tried to get it working in one nine and released kind of another gem and apparently that got a lot of downloads because a lot of people were just like, I just need this library to freaking work on. To work, yeah. Well, the reason I ask is because we were talking about CTFs before the show and just your attitude seems you go by an alias.

And so it seems like privacy is an important thing to you. I mean, you're into security and all that. So I wonder, was there any mean, you're into security and all that. So I wonder, like, was there any implications for you of, like, just getting popular, like, and getting, like, notoriety and getting pointed at for a lot of stuff? Well, I'm very, like, I've always been very anti-celebrity, anti-kind of cult of personality. Coming from, like, the security hacking world,

it's a huge problem um like there's like you there's like you go through cycles where like someone will rise to fame and they'll be speaking at every conference and usually uh often recycling their you know previous talk and um and kind of that that community has developed this huge kind of like immune response to that where if you're not putting out actual useful information, new information, new research, they quickly kind of like forget about you and sort of just like whatever. Like if you're just sort of being a thought leader, you're not really as valued as much as someone who's actually doing like really useful work. So, yeah, I guess I'm very cognizant about not doing that, and one of the things I make sure to do is always give credits to the contributors.

And I also got a shout-out for the user Havenwood on GitHub has been a huge help in maintaining CHRuby. He's helped with always submitting the homebrew, updated homebrew recipes to homebrew, and testing things on OSX because I don't have an OSX system currently. So it's been a huge help. So it's just not me being all like, I'm not super genius here, developing it like in a vacuum.

No, yeah, actually that's one thing that kind of struck me as surprising is that chruby has 30 contributors on GitHub. So obviously there's a number of contributors that actually probably, well, not obviously, but I would assume there's a number of them that have not actually contributed to the shell scripts themselves, but to other things around them. But still, I mean, it's 90 lines of code in the shell script and you have 30 contributors. It's like that's a pretty big ratio. And I think that's neat. I think that's cool to see so many people, like, pitch in and help on different angles. And, you know, you said, like, with the homebrew, and you probably have people that have just updated the readme.

But people care about this and what you're doing, and that seems pretty cool. And also I think what came out of it was I wrote a generic makefile because I was kind of annoyed of how all these shell script projects either they had this really simple install.sh file or they like you curl down and install a script I just really wanted a simple makefile that just installed, worked on BSD and Linux because there's issues with the version of make on BSD

and Linux, the GNU make versus the BSD make and so a lot of those, I guess you have a lot of casual contributors and they fix kind of the minor things. And I think that's really also important open source too. If you see a minor bug, you should probably at least report it or fix it. Because every little fix counts, it does add up. Even if it's like typos in the readme or, you know. This is a jumping forward, but just on the, i hate to put a lot on me because i don't

like to do that whatsoever but you know you talk about little fixes that had a little fix in your public uh ronan um which was like because i was doing some research for the call and i was like oh this link is off but the coolest thing about github is that let me easily click edit fix the link for you and submit a pull request in a couple clicks. And Steve Kladnick had an awesome post on the changelog, I think about a year and a half back, that still gets tons and tons of reads. We'll link out to it in the show notes if you're listening to this.

But like you had said, all those little fixes, 30 contributors, they may not have done the heavy lifting, but they're keeping a line on the edges you know that that you forget or you miss it's sort of the uh long tail yeah long tail principle where the casual contributors do actually add up over time and it's also kind of minor things do actually turn away a lot of potential users and so that's kind of when you do release code you have to be kind of ocd about that um if you see a typo in the readme, they're probably going to like, they're going to be biased automatically against the project.

But yeah, the fine thing about that typo was when GitHub changed to all the user pages to like GitHub IO, I have this git alias, git sed, so I can actually do mass find replaces. And I end up breaking the url on every single page and so i gotta undo that yeah i'm sure that was fun to fix so it's actually really easy using get said but well yeah it was a noise you know i literally changed two characters which was awesome so going then to ronan i think ronan, looking through all the projects that were listed,

I think Ronan was probably the first one, well, not the first one, but one of the bigger ones that I've heard about from you. So why don't you talk a little bit about Ronan and what it is and what's the purpose? Oh, yeah. So back in the day, I was working in a computer security research group. We had this project. Well, I mean i was like thinking like well uh you know ruby is a really great language for doing dsls uh there's already like you know

you could think of rails as kind of a dsl framework uh for doing web development because they kind of wrap everything up and nice helper methods and so it like it abstracts away a lot of the complexities like i'm talking like rails 2 old school um no it's really complex these days but uh so i kind of thought like well hey this ruby language might be pretty useful uh because like i was looking at the documentation for instance they have like a telnet module and it's really nice we can use the blocks to automatically set up the telnet session handle it and then tear it down so i was like wow this can actually be pretty useful for writing exploits because exploits really aren't that complex code wise and you could also then write a lot of the helper methods and make everything basically one line basically doable

in one line of code where you just string together the helper methods and so that was kind of my project with Ronin was to create environments with kind of like an active support type library called Ronin Support that provided all the helper methods, which are called convenience methods, for various things that, like, security research need to do, like, all the time,

and then provide kind of a main kind of console environments and then a system for installing repositories of other people's code. Because, you know, back within, people are still using rubygems.org, rubyforge.org to distribute. So it's a lot easier for your kind of average security researcher who isn't really like a top-level developer. That's not what they're after. They're like trying to do research and break things

and find cool vulnerabilities. And so it was kind of a lot easier in my mind it's like basically just have a repository system they can give a url and it'll pull down some svn or a git or whatever directory of their code and pull it all together but yeah it's kind of one of my big one of my first big projects and that spawned a lot of different other libraries and gems and then because like a lot of code got pulled out of it as it kind of matured um so a lot of useful code kind of got split out of that so i was kind of following the uh the model that data mapper uh followed that basically they split everything up into smaller amounts, smaller libraries over time. And so I was kind of like doing that.

But, yeah, so I kind of got caught up in work, and so I kind of like put Roan more to the side. But now I'm sort of like thinking about how things have changed and definitely want to get back on the project and simplify some various things. So you do plan to get back into Roin? Oh yeah, yeah. There's a lot of unfinished code in there. Gotcha. So this is an interesting, I think this is interesting to me because you were kind of doing security research with Ruby four years ago and the amount that Ruby has changed in the last four years or, you know, in the last X years last X years, you've had to keep up with a lot of change.

What has the process been like maintaining? I think this might be one of the oldest actual projects that is still maintained that we've actually had on the show. What's that been like? There's periods of rapid growth in the Ruby community where we had things like, you know, we switched, we switched to Jeweler, then we switched off Jeweler. And then we had Bundler. And then we kind of like, there's all these kind of evolution of tools. And so it's kind of really difficult to keep up. And we, you know, we went, we transitioned from RubyForge to RubyGems, then RVM came along. So it was kind of difficult to keep up all these tools and actually found myself kind of like gradually moving away from the tools or not just like, it seemed like when any of these tools came out, everyone just sort of like, we must use this everywhere possible, all the time, irregardless.

And I kind of found myself that it's really not that necessary. For instance, if your library has, like, one or two dependencies, and they're probably installed anyways, like the JSON gem or a rake, you probably don't need Bundler. And so, yeah, and also kind of developing these tools, these libraries, they were kind of my personal playground, and so I did kind of, like, develop tools based out of that because I got tired of, like personal playground and so i did kind of like develop tools based out of that because i got tired of like having to always edit the readme that was

generated by jeweler or or by ho or by uh bundler i just wanted to like project set up automatically with like rspec and all that stuff and so i kind of wrote like a uh or which is like a project skeletoning tool and says it has been a bumpy road and it's especially annoying when there's like issues with ruby upstream um like kind of the major like whatever like open ssl would break things or um but at the same time it has been nice where we did develop tools to deal with that where I for instance like a long time i just always recommend people to install rvm first and then you know before installing ronin and like install the latest version but at the same time i kind of felt like you know we were moving a little too quickly and maybe it would have been a little better to sit back and kind of like re-evaluate

what what our actual needs are because like for instance the same thing with how um rbm kind of um inherits a lot of the features and like uh ways of doing things from rvm you kind of also saw that in bundler about how bundler basically also developed its own little static project generation tool and which like was basically constantly being changed and updated and because it's really hard to get get rights first um because everyone has like little nitpicky uh changes to like how they want projects generated and um or it also has like you know it embeds their own release tasks which are kind of like crummy. They don't use proper rake file tasks. And so it will always rebuild your gem irregardlessly,

even if no files have changed. So I kind of felt like maybe a little better to actually slow down and kind of take stock of things instead of just constantly racing around trying to release versions all the time. Yeah. So one thing I wanted to kind of bring up, we forgot to talk about this before, actually,

with CHGems, and sorry to kind of do a huge context switch here. We actually didn't talk about CHGems. Can you just kind of introduce what CHGems is real quick, and I have a question about it for you. So CHGems was sort of my attempt to kind of rethink gem sets because one of the kind of assumptions that go along with gem sets is they're always named and they always are stored in your dot gem directory wherever that is and i kind of want and then also they had to be implicitly uh like auto switched so which kind of makes sense because the majority of the time

like you would have this like rvm gem set file and it would have a name in it and would use that gem set when you cd'd into the directory it would then activate the gem set and i kind of thought that this was like first of all like uh it didn't feel too comfortable of having like this automatic feature and i didn't really agree if always having the gem sets in in your home directory is like why not just put the gem set in the actual project directory in the same way that uh you know you can do a bundler install and put everything in vendor gems and then i kind of decide well let's take a different approach because there's like apparently also a lot of people wrote their own kind of gem set replacement scripts there's like oh my gems there's i said rev that's one version and uh also it was a gs gem switcher

and i basically just wanted to make something that instead of you actually having to like enter into a gem set and then leave because i always would find myself when using rvm gem sets forgetting that i was still in that gem set and being like oh hey that's that's why half my gems are missing yeah then you install a bunch of gems to the wrong gem set and get all pissed off when you have to clean it up right and like or just like you forget about it you've made it for a project that like you know you wanted to make a couple line fixes to this like huge project that had zillions of dependencies. And so you want to, like, isolate it in some gem set.

And then you forget about it and, like, you don't remember it when you're, like, going around cleaning up your home directory wondering why you don't have any space left. Yeah. So I kind of, like, took the approach ofroot, where you can basically explicitly enter into a project, and then that starts a system image, and then it starts a subshell within that system directory, and it makes that the current root. And it's kind of nice because you can basically exit out of the shell, and you go back to your previous environments, your previous system. So I kind of felt that that was a really good model.

You could basically explicitly go into a project and then leave. But yeah, there's actually some problems in rows with that because the way that CO2 auto-switching was expected to work, people who use TMUX, for instance, when they opened a split pane or split terminal, it didn't properly initialize or inherit the shell environments from the other terminal. And so basically a lot of Tmux users requested that chruby always auto set the Ruby version on new subshells. So I had to make that change, and that kind of ended up conflicting with chgems

because chgems spawns a subshell, and so there's kind of this weird race condition where chgems basically sets the gem home and gem path and then passes that to the uh subshell process and then when the subshell initializes uh basically then ch ruby loads and then it resets the gem home and gem path and so it's like it's it's a dicey kind of uh way to deal with it without coupling the tool the the two tools together. Right.

I didn't want to have some sort of flag of do not reload chruby. That would feel like a little too much coupling, even though if it was just one variable. But like, yeah. Let's pause this show for just a minute and give a shout out to our sponsors, New Relic. If you've got a web or mobile application, you need to know about New Relic.

It's your new best friend, basically. It's your easy-to-use analytics dashboard that basically gives you powerful code-level visibility into the real-time performance of your application. So this means that you can spot bugs, see bottlenecks, and fix problems fast, hopefully before they even affect your users. Thanks to New Relic, you no longer have to ship your app to production and then helplessly wait around, hoping for the best until negative app reviews and tweets start to roll in. New Relic empowers you to see what's going on and what is working and what isn't working all in real time. The way it works is really straightforward they give you a lightweight agent that you unpackage into your production level apps that agent sits around quietly and securely in the background kind of gathering

real-time metrics across geographies devices platforms all the way down to the end user level and then displays all that data in real-time graphs so coders can have the visibility they need into the performance of their web applications and make everything awesome. So go and check out New Relic today by visiting newrelic.com slash the changelog to learn more and use the offer code the changelog and take advantage of this special 30-day extended free pro trial available exclusively to our listeners. Newrelic.com slash the changelog. So it surprised me. I don't know.

And I'm not really even necessarily sure why it surprised me, but it surprised me that CHGems even exists in the first place. Yeah. It would be kind of nice if either this functionality was kind of like baked into RubyGems itself, which actually you can do. I mean, literally just set gem home to some path and there you go. It's also the making sure that the bin directory of the gemdir takes precedence on the path. So any sort of executable in there, you can just run and it'll go to that one. And that's another thing I also kind of wish that Bundler would kind of invest time into doing

is provide some sort of shell script you can load that will automatically kind of like detect the bin stubs and put those in the path or set up aliases or something. Just so you wouldn't have to bundle exec every time yeah or install or clutter your bin directory with bin stubs and like which can actually clobber existing files in there which is kind of annoying super annoying yeah and yeah so that was kind of like my kind of like trying to answer that but of course like it is kind of a difficult problem. Is there a definitive blog post or write-up that prescribes how to use chruby,

ruby install, and chgems? We got a lot of new listeners to the show that are just getting started, and we have a lot of very seasoned developers also using it, so we kind of have both chasms. And I'm not sure if i've ever seen a full write-up of like here's why you and i know you're kind of on the show to talk about it a little bit but here's why i did it here's you know why you should use it and here's the implications of using it these you know these several tools together is there a write-up that's just like clear as day? So there's actually lots of write-ups. And I kind of let users write their own. This is kind of the first, usually previous projects,

I'd always kind of like naively put together this project and think like, boy, people are going to love this. And then I post it to Reddit, and then it just gets eviscerated. Yeah, oops. Yeah, and it's basically kind of like that whole, I feel like some of the criticism is valid, but I think a lot of people, they kind of use that as a way to pump themselves up of criticizing other projects. That initial criticism can actually hinder the project and hold you back. And so I literally just did word of mouth marketing.

I just recommended it. Like, hey, here's this thing. Check it out. Make your own decision on it. So users have actually wrote up a lot of different blog posts about their experiences. So literally, you could just Google for, like, CHRuby, and you'll find a dozen or so blog posts. And a couple, actually, in Japanese and Spanish, which is kind of cool. Sort of crossing that language barrier.

And yeah, just kind of give the basic rundown of like, here's how I set it up. Here's, you know, here's how you switch rubies. Here's how you install them. And here's kind of caveats and like, yeah. Because I know one thing that I've always gotten held up on was always having coming from, you know, RVM to CH Ruby, I, you know, kind of depended on gem sets. And I've, you know, with Bundler and the way it handles things,

I've kind of gotten rid of gem sets. I don't use it anymore. Obviously, I don't use CH gems yet. And I haven't really had a need for it. But I find myself only here and there having conflicts um and is that in maybe maybe i don't do enough with ruby to understand why someone would want to obviously isolate their their gem into it their gem you know gems for a project into a gem set but most often the reason you know clearly is for you know just the fact that you don't have any bumps.

There's clear isolation from other projects. Yeah, and also you're using environment variables to achieve this. And so you don't have a lot of the magic, quote unquote, that Bundler does to ensure that it isolates all the dependencies. But, I mean, you should be able to, like, get away with just migrating gem set projects to using Bundler and kind of, like, sharing gems that way. Of course, you can also just directly edit the path and gem home and gem path environment variables and set your gem set that way.

And you just have to then ensure that every time that uh project is ran it's ran in a shell that loads up the configuration and um yeah so yeah actually i've been thinking about like uh there's this tool that someone wrote called rev which allows you to kind of like add you know set and uh reset gem sets and i thought it'd be kind of interesting if someone actually wrote a tool that basically just pushed and popped uh directories on the gem path and then set gem home accordingly and that would allow you to actually like more fine-grained control of the gem directory kind of like search uh search variable the order in which it you know checks all the directories for the for

all your gems and so i kind of felt like you know that'd be kind of interesting uh way to do it but really i mean it seems like there's a lot of confusion about how gem sets work ideally and a lot of people are trying to kind of like reinvent them and explore different areas and so it's not kind of really a solved problem yet in my mind. Does that answer it? Yeah. I mean, it's like you said,

it's a tough problem to solve anyways. And I don't think there's really a one way to do it, but I, you know, I now don't even depend at all on obviously gem sets, but I kind of miss them because I have had some conflicts. Then I end up doing something that Andrew kind of mentioned earlier, which is like obliterate all my gems,

which I have just a – I happen to be a ZSH user, so I just type FO and up a couple times, and I find the most recent for loop that I've written, you know, that basically obliterates all my gems installed. And I just – because they're so easy to install, and it probably even upticks the numbers of installs anyways, I just obliterate all my gems and just, you know just bundle install, and I'm good to go in happy world. So that's okay with me, but it still feels a little dirty.

It feels dirty to not have that segregation. Yeah, yeah, and plus the fact that the default behavior of bundler is to install into the gem directory as opposed to installing always into a vendor directory. And kind of like you get that tradeoff where it's like, well, I can clutter up my gem directory as opposed to like installing always into a vendor directory and kind of like he had that trade off where it's like, well, I can clutter up my gem directory or, you know, I can blow it up the vendor directory. This might elongate the conversation a tiny bit further, but you know, it's, it's, it's impossible to kind of, um,

miss the millions of dollars recently that NPM has gotten to become NPM Inc. And you've got other package managers that come up to play like what is is ruby playing catch up is there something new out there that's being done by npm and bauer and other package managers that simplify the way they're distributing and versioning for individual projects well um actually i haven't looked at npm yet i actually should do that but uh one of the things that is really interesting to me is haskell's package manager uh cabal and it apparently has its own concept of sandboxes and so and also what i really like about cabal is the fact that the specification for your project is literally um key value colon separated plain text.

And so we don't have this like crazy, you know, pure Ruby gem spec, which is really kind of like gem spec was originally kind of designed for internal usage of, you know, describing the gem. And we turned it into this thing where we could actually, because Ruby gems, it's faster for it to load actual Ruby code as opposed to deserializing it. So when you actually install a gem, it unpacks the actual gem spec back into pure Ruby. And I guess this kind of gave people the idea of like, well, let's just put this gem spec into the actual Git repository for projects. And we'll have it list, you know, use Git Ls files.

But I kind of feel that, like, violates DRY, that we have this, like, random bit of code that we constantly regenerate, and it has this, like, you know, Git commands embedded into it. I kind of like the fact that, like, Cabal hides a lot of that from you. And what I actually do for a lot of my projects is I put all the metadata into a jump spec yaml file and then

my jump spec is basically just boilerplate code that loads that file and sets all the fields and also like Cabal and Haskell's GHC compiler has a really advanced dependency tracking system where it can actually recompile code

that detects some change somewhere so really interesting yeah i mean you mentioned you haven't looked into mpm much but one of the ways it does um package installation is you can pass it a fly to say um you know save to local basically so it's dash dash save or you can add a dash dash save dash dev onto it and it and it actually uh will either go global if you don't do dash save i think you might have to pass the flag dash g to it uh possibly so somebody correct me if i'm wrong but but then it also just drops into your project um most often hidden if you're hiding it with your editor you know with your ID or just sublime text, whatever you use. But then it drops it all into node modules.

And from there, you have them locally with your project. And that way, you kind of don't have this gem set need. You almost just have your project, and you either save locally or you don't. You just either install globally or install locally. And it just pulls the version that way. I mean, so far i've you know kind of been dabbling in some javascript development and it's been coming from the ruby world into that world i've saw kind of both sides of the fence and it's it's neat the way they handle

it and no conflicts yet so it's yeah i don't quite have the job you do of maintaining this project and the and the dependencies it has against it but that kind of neat the way they do it oh yeah totally um yeah i definitely feel like kind of the uh challenges uh that ruby switchers have to deal with is kind of uh dealing with the environment variables that you use to then manipulate um how ruby gems operates and sometimes it would kind of be nice if if it did automatically detect.gem directories, and that's just how it works. But, of course, there's security issues with running into malicious gem directories. Yeah, you've got a security background,

so you're thinking not only how do you use it as a developer, but how do you securely use it as a developer? Right, right. You know, because, you know, we pull down tons of code every day off GitHub. Right? Yes, quote, unquote, trusted. And, like, it would be very trivial for someone to have, like, for a lot of those tools that automatically load environment variables

when you CD into the directory. And you could totally convince someone to do that. And, like, you would have some sort of way to manipulate the path where you can actually redirect it. So instead of typing LS and using system LS, all of a sudden using their weird backdoored LS or backdoored suit. Right. So that's kind of it.

So not to hijack the conversation too much, but we are kind of running up against our time limit here. So I want to go ahead and ask our standard set of questions for you, Postmodern, if you're okay with that. The first one is for a call to arms or a call to action for the open source community on any of the projects that we've talked about. Okay. So I've actually been thinking about writing a blog post about this, but it's probably better just to put it into words here.

So this is like super, super radical thing to say, but you do not need a Ruby manager or switcher in production if you only have one Ruby. And this is just something that people, not necessarily the word cargo cults i think applies but we just have gotten used to doing it and then that's just how we do it and it's baked into all these configuration management tools like chef and puppets and you just don't first of all the package managers ruby is usually roughly up to date um the latest version of ubuntu available

on amazon uh it's it's recently up to i think it's 193 Ubuntu available on Amazon, it's recently updated. I think it's 193 still, but they're going to bump that to 2.0. And of course, there's still GC issues with MRI 2.1. And even if your system, and the benefit of using the package manager is you can enable things like unattended upgrades, where the package manager will automatically apply security updates and just have to restart your processes, and that's really nice, as opposed to actually then freaking out at, you know, 3 a.m. in the morning

and, you know, doing RVM get ahead and installing the latest version to deal with some sort of critical security vulnerability. And also, even if the package manager doesn't offer the most up-to-date package you can roll your own packages with fpm you can also install the ruby into usr local and that's the purpose of usr local and the whole unix file system hierarchy is that it's for all the software that you install that's not installed by the system so So like USR is controlled by the package manager. The administrator controls USR and on most systems,

a USR local bin always comes before USR bin in the path. And so any software install there overrides the system software. And like, I feel that a lot of people kind of like miss this. And I feel like setting up a, you know, production environment shouldn't be that difficult, and you just really need to install a package

or extract a tar of a pre-compiled Ruby, and it's not that difficult. So just to clarify, I believe this is the first time that the call to arms from our guest has been to not use their project in production. Yeah, you don't. It adds so much more complexity of making sure it works with all these system components.

And it's really more, the Ruby switcher is more optimized for developments and, you know, testing things. Because, like, seriously, it just makes it so much easier. Awesome. So the second question, if you weren't doing what you're doing now, what would you be doing? Oh, man. So you mean like open source or work-wise? Well, anything. Surfing or work-wise or what would you do with your free time?

Yeah. Oh, man. Probably writing like various security exploitation tools. That's kind of on my list of things to do, which technically I do sort of do for work, but yeah. There's a back end to that question too, which is maybe an open source project out there that you've wanted to hack on,

but you've got obviously a list of things you're doing doing but you haven't had a chance to hack on it what's you know what's uh what's something you've seen out there that you wish you had time to hack on that you don't and you would love to if you had a weekend oh man okay so there's actually a couple of projects that i feel that really could use some like extra help and simplifying things and kind of like exercising out the really bad uglyifying things and kind of like exercising out the really bad ugly code that's kind of built up the technical debt and one of the projects that we're really loving recently is padrino um i feel it's a really nice layer on top and they they've been doing more than just building on top of sinatra they have their own custom router

and it feels very structured has that nice really Rails 2 structure feel, but without all the complexity that now comes with default Rails. But a lot of the code in there is kind of messy, and I feel like it would kind of benefit from more people kind of looking at it and figuring out maybe better ways of handling things because a lot of their features are built on top of kind of like Sinatra before filters conditions, Sinatra conditions, and rack middleware. And so there's some weird issues, for instance, when you want to disable CSRF protection

on certain routes only. So yeah, really awesome project. The other one also is the ROM project, Ruby Object Mapper. Where is that? I've been waiting for that forever. I know, same here. And basically I've been always talking with the developers

and I'm usually very skeptical because they kind of tend to take principles to the extreme. And this kind of results in a lot of excess code that is more kind of writing the code to comply with the style checker or the co-complexity scanner or something like that. So I've been slowly going through that project and just sort of making small pull requests,

but I'm just one person trying to undo complexity, and that's usually hard once it's manifested. Yeah, ROM would definitely be on my list of projects to help with. And like you, I would imagine, I love using Sinatra and DataMapper in the past, and so I've been waiting for ROM for quite a while now. Oh, yeah. Because DataMapper 1 definitely has its warrants.

Yeah, definitely check it out and try to contribute. They're actually pretty close they have read supports but they still need to get write supports okay so the I guess the last project I'd have to say worth checking out is mRuby and Ruby is really well designed I would have to say of kind of embeddable languages I've been I was looking at those a couple years ago and it seems like every kind of language that claims to be embeddable languages. I was looking at those a couple years ago, and it seems like every kind of language that claims to be embeddable is basically more designed to be installed onto a system

and then loads its additional modules via extra shared libraries. And MRuby is really interesting. It has its own little build system that compiles all of its features are split into what are called MRB gems, and then those are all compiled down into one single static linked library that you can then embed into other programs.

And so, man, it's really nice. And it has actually pretty decent documentation around it, but there's not a lot of projects around it, so you do have to do kind of your research and tinker around with the code. But it's really well put together and i think has huge potential and just uh anywhere you could put lua uh the embeddable language lua you could probably put mruby and do a lot more because you know lua misses it lacks certain thing basic things like bitwise operators yeah cool so the last question

is uh for a programmer hero or just somebody that's been really influential in your life to this point. Oh, man. So I try to be really anti-hero because anti-hero worship, I feel like it really holds people back when they're always kind of looking up to someone

instead of someone inspiring to, you know, improve themselves and challenge themselves. But I definitely have to say, like, as far as, like, programmer wisdom goes, I feel like Dan Cub, who worked on the Data Mapper project, Piat Silnik, and then also Marcus, I'm going to mispronounce his name, Marcus Schreipt, MBJ. He wrote Mutants. Yeah. And those people are kind of like the most interesting discussions about design and when principles are taken too far, when they're not applied. Like pretty much anything Solnick writes is like I pretty much agree with it.

So those are kind of like they're hip cats. They know what's up. Yeah, for sure. Awesome. Well, I wanted to say thanks a lot for coming on the show. I think that this is a, I don't know, you kind of get the sense with Ruby Switchers and just with this world that we've almost gotten as simple as we can get, but at the same time it feels like we've got a long way to go, right?

I mean, your call to arms kind of sums it up, right? And that, like, the goal would ultimately be to not really need these things. And so, you know, I think that we've got a long way to go here, but I like the simplicity that you're aiming for. So once again, I just want to say thanks a bunch for joining us today. It was Postmodern. His real name has been redacted. And once again, I just want to say thanks a bunch for joining us today. It was Postmodern. His real name has been redacted. And no, I'm just kidding.

But yeah, no, for sure. We will be back next week. So make sure you listen. We are going to start doing this weekly again now that everything has started to settle down. Back to live, too. I think we're going to be, if you're listening to this obviously you are because you're hearing me say this but uh our our new date is friday live at 10 a.m central standard

time um if for some reason we don't have a guest we're just gonna get on there anyways and just talk about awesome open source so we're we're aiming for weekly live um should be a fun time and a post-monitor we've we've uh been playing some email tag for a bit too trying to get you So we're aiming for weekly live. It should be a fun time. And at Post Monitor, we've been playing some email tag for a bit too, trying to get you on the show and just echo Andrew's thoughts too, just ecstatic to have you on the show. Love the work you're doing at Open Source and just want to do as much as we can to encourage you to keep doing the awesome work that you're doing.

Thanks, man. It was a fun time being on the show and hope to hear more awesome episodes out of you guys. Thanks, man. It was a fun time being on the show and hope to hear more awesome episodes that you guys. Absolutely. Go ahead, Andrew. Uh, yeah, that's it. So until next time, we'll just say goodbye.

Bye. Bye. Adios. We'll see you next time.