The Changelog: Software Development, Open Source - Bringing Atuin to the desktop (Interview)

Episode Date: October 22, 2025

Ellie Huxtable's magical shell tool, Atuin, won developers' hearts by syncing, searching, and backing up our shell history with ease. Now Ellie is tackling the desktop with a GUI built to help teams make their workflows repeatable, shareable, and reliable.

All right, welcome. You are listening to The ChangeLog, where each week we interview the hackers, the leaders, and the innovators of the software world. We pick their brains, we learn from their failures, we get inspired by their accomplishments, and we have a lot of fun along the way. On this episode, I'm joined by Ellie Huxable,

whose magical shell tool, at Twin, won developers' hearts by syncing, searching, and backing up our shell history with ease. Now, Ellie is tackling the desktop with a tower-based app built to help teams make their workflows repeatable, shareable, and reliable. But first, a big thank you to our partners at fly.io. The public cloud built for developers who like to ship. We love Fly. You might too. Learn more about it at Fly.io.

Okay, Ellie Huxable, back on the changelog. Let's do it. Well, friends, I am here with a new friend of mine, Scott Dietzen, CEO of Augment Code. I'm excited about this. Augment taps into your team's collective knowledge, your code base, your documentation, your dependencies. It is the most context-aware developer AI, so you won't just code faster. You also build smarter. It's an ask-me-anything for your code.

It's your deep-thinking buddy. It's your stand-flow antidote. Okay, Scott, so for the foreseeable future, AI assisted is here to stay. It's just a matter of getting the AI to be a better assistant. And in particular, I want help on the thinking part, not necessarily the coding part. Can you speak to the thinking problem versus the coding problem and the potential false dichotomy there? A couple of different points to make. You know, AIs have gotten good at making incremental changes, at least when they understand customer software. So first, in the biggest

limitation that these AIs have today, they really don't understand anything about your codebase. If you take GitHub co-pilot, for example, it's like a fresh college graduate, understand some programming languages and algorithms, but doesn't understand what you're trying to do. And as a result of that, something like two-thirds of the community, on average, drops off of the product, especially the expert developers. Augment is different. We use retrieval augmented generation to deeply mine the knowledge that's inherent inside your code base. So we are a co-pilot that is an expert and they can help you navigate the code base,

help you find issues and fix them and resolve them over time much more quickly than you can trying to tutor up a novice on your software. So you're often compared to GitHub co-pilot. I got to imagine that you have a hot take. What's your hot take on GitHub co-pilot? I think it was a great 1.0 product. And I think they've done a huge service in promoting AI. But I think the game has changed. We have moved from AIs that are new college graduates to in effect AIs that are now among the best developers in your codebase. And that difference is a profound one for software engineering in particular. You know, if you're writing a new application from scratch, you want a web page that'll play Tick-Tac-To, piece of cake to crank that out. But if you're looking

at, you know, a tens of millions of line code base, like many of our customers, Lemonade is one of them. I mean, 10 million line mono repo as they move engineers inside and around that code base and hire new engineers, just the workload on senior developers to mentor people into areas of the code base they're not familiar with is hugely painful. An AI that knows the answer and is available 7 by 24, you don't have to interrupt anybody and can help coach you through whatever you're trying to work on is hugely empowering to an engineer working an unfamiliar code. Very cool. Well, friends, Augment Code is developer AI that uses deep understanding of your large code base and how you build software to deliver personalized, co-suggestions, and insights.

A good next step is to go to augmentcode.com. That's A-U-G-M-E-N-T-C-O-D-E.com. Request a free trial contact sales, or if you're an open-source project, Augment is free to you to use. Learn more at AugmentCode.com. That's A-U-G. M-E-N-T-C-O-D-E dot com, augmentcode.com. joined once again by Ellie Huxable with A-to-in, which has been making my show magical for years now. Ellie, welcome back to the change log. Hi, great to be here. Great to have you.

You sound closer. You were so far away last time. I think we had to schedule around our different time zones. But now you're in the States. What happened? What changed? I moved to San Francisco. That's been very recent just like a month ago, but it's been good so far.

Good so far. And where were you before somewhere in the UK, right? I was in London. In London. Okay. And you were often on a motorcycle. I remember that part. All the time, yeah.

Still am. I bought one like four days often moving here. So that's a... Did you upgrade? Did you downgrade? Did you side grade? Side grade. I have a 1290 super duke now.

The roads here are more fun and the weather's more amenable to motorcycling. Okay. And they're in SF. You're in the San Francisco area? Is that you said? Yeah. Yeah.

Lots of hills. Yeah, that's fun too. Fun, aka dangerous, depending on your average. appetite for destruction, I guess. Pretty much. So A-to-in, such a cool tool. Very few times do I cover a tool in ChangeLog News and then install it and then use it.

And it integrates itself into my life. And it's been years now. So I just use it happily. Control R for the win. I love it. I don't use probably any of the fancy stuff that you've added since then. But that was like your deal originally was A-2-N, the C-L-I, which is like synchronized. and prettified and just better, in my opinion, shell history.

And the Sink was really a big part of what you were building, which is a part that I don't care about. I'm a one computer person. You can use it to backup as well. It's pretty good for that. Yeah, that's true. And you have some cool stuff with like how you're handling Sink and how you do that without, you know, violating privacy.

And there was all kinds of talk about that. And then you continue to work on it. And now you're working on something that's very related. and very cool and different, which is A2N desktop. Can you take us on the journey from when we last spoke, which was about 18 months ago, on the show about A2N, the CLI,

and where you went from there, what you built? Yeah, sure. So the CLI records every shell command you run. That's kind of the whole point. It makes it really easy to recall them. But what is trickier with that is sort of recording whole workflows. So if you're looking for an individual command, it's great.

it's really easy. But if I was looking for, like, how do I set up a new staging environment? How do I on board a new developer? How do I do something that's a long sequence of steps and maybe needs annotations and various other things? The CLA helped but didn't solve the problem. We had a whole bunch of discussion over years, to be honest, like I've had this idea for a really long time of like, how can we solve this essentially documentation problem? And Atta and Desktop, the answer there, at least in my opinion. So what it is is essentially a runbook editor, and what I mean by that is we started off by just building something that was good for recording notes and documentation. You can just write English words down and share them with people.

But where it gets really powerful is the executable blocks we added. So we have things like terminal blocks, which are, if you imagine, notion where it's like database blocks. Instead of a database, we have an embedded terminal that you can actually execute a command. And this sort of takes it from like a confluence page that goes stale to something that you can actually run and read in the same place. A lot of people have asked how this is relevant to the CLI, and I can kind of see that it might not be immediately obvious. However, where it does become quite powerful with the CLI is all of the data you've been recording in your case over years in the CLI is accessible in the desktop app too. So you can screw around on your machine, figure something out locally in your terminal, and then when you go to document it later on, you can write down what you did and you can

pull in your shell history into the executable blocks. Yeah, that's really cool. Yeah. That's really cool. So if I recall correctly, you had full-time jobs at one point, which was a Murr Post-Hog. What was it? Was it Coinbase before that? Okay.

So a couple of serious jobs. And then you had quit your jobs in order to do this, open source, you know, try to make a sustainable, live in the dream, so to speak. And there was a question on like, well, where do you take it from here? And the desktop seems like a good place to take it because you're not just syncing for people. You're providing collaboration. You're providing tooling around docs.

And these are the people who are generally speaking, like running infra at corporations, right? So is your end user basically like, is DevOps still the term? I don't know, a platform engineer. I'm not sure they're calling themselves today. Maybe like a separate conversation, but I think DevOps kind of like failed. DevOps is over. But no, it is sort of platform, SRE DevOps, like whatever you call it, people that do SSHing and Kubernetesing stuff for their jobs. We used to be called SISadmins back in the day.

I feel like we abandoned that because we wanted to get a raise, you know? But at the end of the day, I mean, you're administering systems. So I like the term SIS admin. I always have. I probably always will. How does it work? I mean, how is, are you, are you presenting? out and said Atuin?

Atuin, yeah. Etuin. Kind of like Tatooine. Pretty close, actually. Pretty close. Maybe we should change the logo to have like a turtle and a desert planet. That would be pretty cool. That would be cool.

The turtle is cute though, so that always gets me going. But Atuin, desktop. How does it work? Oof, there's a lot going on. It was an easy question for me to ask. It sounds like it would be a hard one view to answer. Yeah, so I mean, at a very high level, it's a desktop app. It's not an electron app.

It's a Towery app. I'm not sure if I'm saying that. correctly, which is a web view, but it's your system web view instead of a copy of Chrome and the backends all written in Rust, which I'm very happy with instead of Node.js. Talk about that more if you want later. But we essentially launch a web app locally in Towery and it contains an editor called Blocknote, which is a really cool open source project built on top of TipTap and Prows Mirror that provides like a block style editor. And we extended that with all of our custom blocks. So to off with you're just editing you have a choice between a local file which is currently

essentially jason we're working on that uh yeah i'm all sorry but again working on that um or you can use our hub which you sign up for you can create an organization or single player and it provides sort of automatic syncing offline first uh editing and the idea that being like collaborative style features um you can have like multicars with people all zooming around which we can see being really useful for incidents or helping someone figure something out, as much as of it as possible is implemented in Rust. So right now we can't, again, we release this as a beta. There's still a lot of like right now it doesn't, but it will going on.

But a lot of the execution is written in Rust. And the idea there is we can bring it to be a runtime, which is embedded in the desktop app that runs in a CLI all over the place for executing runbooks. My kind of long-term vision there, I guess, is that current automation is. is kind of an all-or-nothing approach. You start off with, you know, someone might maybe have documented something, and that alone is a stretch.

Or you kind of have to write a million lines of YAML and have it 100% automated. And we find that there's very little in the middle. There's no, like, happy medium. And a lot of the time things just end up documented or not even written down because the automation is just such a high barrier of entry. The idea of the desktop app

is to kind of make it easier to meet people where they might be comfortable, and that might just be writing down what you need to do, but it might be automating the whole thing with our blocks and then running it with our runtime. So it's designed to be flexible enough to handle most sort of abilities. So it's probably a group of our listeners who, when you say run books that run,

which is one of the catchphrases for Attoin desktop, they live in run books. they write, run books, they copy and paste stuff all the time, they use their shell history all the time. And then there's other ones more like myself who, I mean, okay, I used to be a system administrator, but most of the stuff that I have to deploy or manage at this point is like dot slash setup.sh or deploy.s. And I can just have a little script and it's good enough. And so that's at least my perspective. And there's probably like, you know, a continuum of those folks. for those who don't understand runbooks all that well besides like it's a it's a script of some kind

or it's a list of things that I must do can you expand more on what kind of stuff a runbook can do and how they're usually used yeah um we find a bunch of use cases it could start off just being super simple almost like what you might write a read me for in in our system anyway so you know go install these dependencies you run this migration command run this command to generate some fixtures, et cetera, et cetera. So it can be very sequential, run this, do this, do that. But we also find that people use them a lot for like database operations. So maybe you need to run a whole bunch of SQL to set up a new schema or migrate from

one system to another. And we've made it flexible enough to make that easier too. So our drop downs, you can power with the output of a shell command to select like an environment you might want to run in or a URI that you might want to use in a query. There's a lot of database use cases too. But also, we use them a lot for our local development. So there's like a collection of maybe values in a local database you need to tweak or files that need generating. You can use them a lot. So you might have a home lab somewhere that has a bunch of setup required. And everything's going to run over SSH too. So it can show

you, yeah, you can use it for setting up a remote system too. So maybe you need to set up your Z-FS and then you need to install K3S or Docker Compose or however you're owning things and it can help you with that too. So one of the challenges I think with this, especially in the

diverse world of computers that we live in nowadays is different stuff on different people's computers. So this helps with seeing, I mean, because of everything, if I'm using this as a team collaboratively, right like through your hub i'm not sure if there's a separate thing i can you know self-host or

whatever we can talk about that but i'm sinking the run books across a team and we're collaborating on those things and that's all well and good oftentimes our environments are like drastically different and so we've tried to throw containerization at that like trying to help fix that is there any sort of concept or help with regards of that inside of etuette we don't currently but it's something i'm really actively thinking about um we find a lot of people right now just have like a dependencies step that does its best to set up the dependencies that you might need. But obviously, like you say, someone else might have a completely different local system than you. The only approach I can think of so far as having a container integration, so we have the

concept of contextual blocks, which you would use for specifying that something needs to run over SSH. Currently thinking of doing something similar for containers where I can say, you know, this should run in my local development container and it will sort of transparently make that work. I'm not a huge fan of it as an answer I find containers for local dev to be clunky especially on Mac but I'm also not sure there's actually anything better

so right turns out maybe Linux is the answer in that case I mean that's I've been on my Mac for a very long time and I've had this exact complaint for a very long time and it doesn't seem to be getting resolved at any point and so everyone else is like well we just use Linux for dev it's like, well, that seems like an answer. Especially recently, I've been more and more tempted.

Yeah. As has a lot of people, I think the, I think the luster and the excitement around Apple's products and ecosystem has just kind of like tarnished a little bit. Even I used to be very excited. And maybe it's just like, well, they haven't really changed much. Even like the iPhone events and stuff like that. Like I used to like plan my Monday around the keynote and like let. let's watch it on the big screen and I can't wait to see it and then let's go and we even have

shows we used to comment we still do at times but like just like react to the Apple announcements and honestly like especially the last one like I didn't even watch it I was just like I don't yeah I didn't even know what I changed for a few days it's like it's another new phone maybe I'll get it because it's been three years but my current phone still works and it's just like although they just released some MacBook pros and so maybe I'll go look at those and change my mind But, yeah, it's definitely, maybe that just shows age and exposure. Maybe not just age, but like exposure over time for all of us to these things. It's been like decades of kind of the same thing, just iteratively better.

Anyways, a bit off topic. I definitely think that Linux is gaining mind share once again. Maybe not once again, but in a new group of people that it previously didn't have mindsharing. and fast containers for dev is one reason why that might be nice. I actually found the new Asahi Asahi, however you say it, the Linux on Mac OS. I have another Mac that's running that, and it's incredibly good. Is it? A lot of my experience was like running Arch on a MacBook in 2015, and that was dramatic.

Whereas you install this, and it just works, which was really cool. I recommend it to be able to. That is super cool. We try to do a show on the Asahee or Asahi Linux. And those folks are hard to get a hold of. They don't like to come on podcasts if you know anybody. And you can put in a word because it is fascinating technology. But they're a shy bunch, that's for sure.

What have been some of the challenges with this? I mean, you've been working on it for a couple of years. What have been the hard parts? With the CLI, the hard parts, realistically, have been the sheer amount of data people have. So if we ever want to change anything with database schemers, it's a migration, which, like, you know, professionally when we run a really big database migration, it's like, let's really pay attention to what's going on here. Whereas when we release something, there's like hundreds of thousands of database migrations

going on. And if one of them goes wrong, that's someone who's lost data and we have to figure out how to recover that. So it's very, like, mistakes I might have made a few years ago are sticking around. Right. With the desktop app, it's a different set of challenges. I think it's very, the CLI is quite simple. A command line environment is, it is very varied, but it's still a terminal.

You still have command control sequences and various other things. With the graphical app, it's a bit different. People running it on macOS, it's reasonably a consistent experience. But people on Linux, who I really want to support as best we can, the graphical environments differ hugely. So making sure things run consistently for different people has been kind of hard. We kind of, we joke, there's two of us working on it. joke that we're sort of building a terminal and a text editor at the same time. And neither of

those things are known as particularly easy things to build. And they're kind of dramatically different too. I mean, the desktop, besides, like you said, kind of the spiritual ties between and the fact that you can pull in some of that shell history into the desktop, I mean, they're kind of a wildly different products, aren't they? I think so. I think they solve very similar problems. It are all about knowing what to do next and not forgetting what you've already done. And I think when you're looking at a shell prompts that does not have any shell history and does not have any good documentation, it's very much like what you can remember,

what you can figure out and what you can Google, or I guess these days, ask an alarm. Right. But we're trying to solve the problem of making the shell really easy to use, making repeatable workflows quick and easy. And when you look at it that way around, they are kind of the same thing. it's just trying to solve like an ecosystem of problems rather than just one. And so why did you go to the desktop

if you could have just taken the shell and maybe done a 2E or expanded it? I mean it kind of is a 2E already, right? But expanded it and put this kind of functionality in where it already existed. Why did you decide to start fresh with a graphical interface? Yeah. So the end goal is to have both a 2E, a CLI, and a desktop app.

But I think the desktop app is the most revolutionary change. I'm kind of putting myself on a pedestal, I guess. But there's a lot we can do in the graphical app that you either can't do with a 2E or feels clunky. The editing experience we can give people in a desktop app is a lot better than we could provide in a 2E. We have another example.

We have Prometheus Blocks. So imagine you have a runbook that is how to react to an incident and you can have a chart in your documentation that's real time with a terminal underneath it that lets you change stuff and you can see what you're doing and what reaction that has at the same.

same time. And doing that in a 2E, I'm sure we could probably render a chart somehow, but it wouldn't have the same impact and it wouldn't be as explorable. And a lot of what we're trying to do is make it exploratory and make it something where you can, things aren't quite as strict. They don't necessarily have to run in order. And again, fitting that into a 2E is not as straightforward. An early prototype was actually a web app. So if you think like a Jupyter notebook style experience, where you run like a server and then you open it locally. And I didn't really like how that felt. I think we couldn't integrate with the system quite as well,

even with the web app angle. And the desktop feels a lot nicer. We're not necessarily shutting off any of these things as futures, future sort of expansions, but the desktop's, I think, where it starts. I like to think a bit more as you're putting a terminal into some docks and not put some docks into a terminal. What if AI agents could work together just like developers do? That's exactly what agency is making possible.

Spelled AGN, T-CY, agency is now an open-source collective under the Linux Foundation, building the internet of agents. This is a global collaboration layer where the AI agents can discover each other, connect and execute multi-agent workflows across any framework. Everything engineers need to build and deploy multi-agent software is now available to anyone building on agency, including trusted identity and access management, open standards for agent discovery, agent-to-agent communication protocols, and modular pieces you can remix for scalable systems.

This is a true collaboration from Cisco, Dell, Google Cloud, Red Hat, Oracle. and more than 75 other companies all contributing to the next gen AI stack. The code, the specs, the services, they're dropping, no strings attached. Visit agency.org, that's agn-t-c-y-c-org to learn more and get involved. Again, that's agency, A-G-N-T-C-Y.org. How has it been working with Tauri as a platform? We've done a couple of shows on it. We haven't seen very many production apps out there.

There are. They are out there. It's not trying to belittle it. But it hasn't been a huge upswell. Electron still is the 800-pound gorilla in the room. Generally, very good. There are some issues that the team are aware of and are working on. So firstly, the development experience has been really nice.

Being able to write roster has been really good for us, especially. We're doing a lot of systems-y stuff. Being able to include all. all of the libraries you've already written, has been awesome. It's a lot lighter as well. So when someone downloads like a 20 meg package, it's a lot nicer than asking them to go download like 5, 6, 700 or whatever electron apps are now.

The resource usage is lighter. I don't know if it's necessarily as light as people might say because you are still running a web browser. It's just not another instance of Chrome. Right. As you proliferate Tauris, you're not going to have multiple. multiple Chrome meals in the background.

But if you're just going to run one, you're still going to run a full Chromeium, right? Gotcha. MacOS has been nice because every user is, you know, they're using the same web view that's consistent as what we develop on. So it's fine. Linux has been, honestly, I thought it would be worse.

So it's a lot better than I expected. Tarion Linux currently uses an old WebKit version, which has some performance problems, is not as, I think of the performance is when there's a large number of DOM elements. There are several very long GitHub issue threads, if anyone's interested. But it's luckily for us being mostly OK on most systems,

but it's not quite as performance as it could be on macOS. The team are looking to use Chromium embedded framework on Linux, which would solve the performance problems, but I'm not sure if that's just doing Electron again. But what has been good for us is, again, the rust on the back end, means that anything that needs to be fast, we can make sure it's really fast rather than it's all JavaScript. So another opportunity you had with this project, it was a fresh start.

Codebase-wise with Atwin, CLI, I would say the reception to it that I see and that I have was like universally positive. It's just like, this just makes my life better, open source, but the question is like, can we make money off of it? Who knows? And now you come out with a desktop app and it's like an opportunity to make some money, but also open source, like you're following that same pattern.

So your thoughts on that. Yeah. So the CLA was, I mean, I could definitely charge people for hosting. I've had a number of people say, oh, let me pay you single digit dollars a month for shell history hosting. And that was nice.

However, like the way I looked at it was, I don't want to work on shell history by myself forever. So it needs to have the potential to do more and it also has to have the potential for it to be more than just me. And we have something like 26,000, 207,000 maybe people sinking their shell history. And I worked out that like realistically, 100% of them are not going to sign up to pay. It's going to be quite a low amount. And we can't charge very much for it.

So it's quite a niche realistically. It also really doesn't cost very much in terms of infrastructure to run. I self-host the Postgres on a Hessner machine. It's cheap. It's really performant. And other than my time, it's not a big sync. Desktop, I think, has a lot more potential in terms of, like, business project. There's a very direct organization use case, potentially even stronger than the single player use case, really.

And there's a lot more scope to do really interesting and flexible things with it. It is open source. It's Apache 2. What is not yet open source is the hub for syncing. So we have two times. of workspace, you can have an offline workspace, gives you local files on your disk, you can put them in Git, you can put whatever you want, basically. But the hub is the synchronizing real-time backend, and it's not open-source right now. Basically, we haven't figured out what to do with it yet, and I would very much rather have

something closed-source, and then six months from now decide to open-source it, then open-source something, realize I've backed myself into a corner, and then have to do a horrible license change, and it's a nightmare. Right. Yeah, what we say around in these parts is rugpole, not cool. So definitely keep your cards close to your chest. And then if you want to flip one over and show that you get the ace of spades later, fine. Go ahead and do that.

And I feel very strongly that if you're running it on your machine, it should be open source. Like if it's a desktop app, you should be able to see what's going on. You should be able to change it. Yeah, I think that's a good distinction. Everything else. That's a good place to draw a line in the sand, I think. And I think you're right because when it comes to run books, I just feel like anybody who's playing single player don't care that much about something like this because they got their scripts

they might have a notion or obsidian and they're just like have their docks in there if they write down or it's all living in their head like usually we need a run book it's like hey i put together how we do this now we can all run it when i'm on vacation or you know whatever happens when it's your turn to be working and not my turn and so it's almost de facto team right like it's going to be collaborative. Obviously, there's the outliers who will be using it because they just like your software or whatever, or it's a prettier way to manage their own docs and scripts. But for the most part, I do think it's going to be something that organizations will adopt. Whereas the CLI is like just like hackers and nerds, you know, sure they work in an organization, but it's going to be harder for them to get their org to, you know, sponsor. Exactly. And like the only, the only real way I could see the CLI applying to an org is like share your shell history with your team, which I don't think anyone. one's ever going to want to do because it's weird yeah it is kind of weird it's like at first you're like that'd be great and then you realize all the things you type me like no i don't know it's like my team seeing my browser history there's not anything weird there i just don't want to yeah it just

doesn't it's just a useless and maybe embarrassing at times you know you're like sometimes i type things that is wrong you know or i feel like a command's going to work and it doesn't and it's like there it is it's my shell history absolutely we have heard a lot of people ask about self-hosting it which is yeah something i really want to support but there's there's also the other angle of supporting it, and I found with the CLI that it's self-hostable and has been forever, and it's tricky to support people. Generally, the Docker Compose, we provide works, but a lot of the time people want to run it differently, they want to do their own thing with it, and supporting that's super hard.

So we're now kind of at the point where it's like, unless you're using our Docker Compose and it doesn't work, I probably can't help you, mostly from just a time and energy perspective. With the desktop app, I wouldn't really want to be in the same place, and it is a lot more complicated to run for the back end. So if we do open source it and I would like to, it would definitely be a like you can run it. It's on you. Yeah, yeah, that makes a lot of sense,

versus like a GitHub enterprise thing where you're going to go install it on their premises and operate it for them. Yeah, that makes sense. Did you, going back to the CLI and potential monetization, people are desiring to give you money, you know. And that's because they love the work that you do. And I've seen that online, just the response to it as almost universally positive.

It's very good software. People love it. They seem to love you. And they just want to give you money. Did you try even just turning that lever on, like even though it might not be your end goal or something that you want to work on? For a long time. Well, what about the self or the host of sync?

Like, let me give you a two bucks a month to do this. I think that changes what it is. Maybe someday I will, but I think realistically, it doesn't cost me very much to run, and I'm quite happy providing it as just a thing people can use. The two bucks a month, I mean, I guess, but then it's becomes like supporting people because there's suddenly like, you know, they're paying their actual customers. It's a strong expectation there. But we haven't had any downtime in like a year, so it probably be fine.

Probably. Sounds like you designed it pretty well And it's relatively efficient Like you're not having to Constantly be working on it And maybe upgrading Whether it's vertical or scaling

The other way So that's nice Remember when Radiohead came out With their N Rainbow's album And it's like pay what you want And I don't think Free was an option on that one But basically

I mean you could do something like that Where it's between zero and N dollars Where N is whatever you want to give me but zero is what it costs. I think you have a not insignificant amount, which could also be called a significant amount of money. You know, maybe put some petroleum in your motorcycle or something like that. It's quite expensive these days.

It is. It's not getting cheaper. Yeah. I think, honestly, for me, it's like I want to explore what we can see, what we can do with the desktop app and then maybe the future of the CLI might change. but it's where it is now, I'm super happy with how it's going. I'm super happy to let people just have it and use it.

Realistically, my thoughts on monetizing open source software are more around individuals just use it for free, go have fun, and then it's the companies that should be paying. They get a lot out of open source, so. So how has the reception then been to the desktop release because it's in beta, it's out there, it's open source, and it hasn't been very long, maybe a month or so that it's been out yeah it's been it's been really good we have opt in

emphasis on opt in telemetry well nice i screwed that up it's actually opt out but you can opt out on the launcher so it's okay so it's opt out but you just click a button right it's right in your face when you start it up so it's easy and it's pretty much what we gained about thousand sign-ups on the hub which was really cool to see we've got people making hundreds and hundreds of run books which is also really cool to see I think the biggest thing for me, though, rather than that, telemetry is more the community response. So we have, in our Discord, we have a separate channel for the desktop app.

And people have been in there really active using it. GitHub issues usually imply there's an issue, but it also implies that people care enough to actually tell you that something's not working for their use case or something's going wrong and provide, like, a bunch of steps. We've had people provide some, like, actually really thoughtful GitHub issues as well, which has been nice to see and nice to work on. I think for me, it's also good validation. So, again, I've been working on this for around a year in one form or another.

And we did release in a closed beta back in April, and that had a nice reception. But it's the validation of you can go download it right now. It's on the website, go try it and let us know what you think. And that going successfully as well, which is really nice validation, that the problem that I see is a problem and that I have built a solution to is a problem that other people see too. Yeah. Well, I did download it. I'm staring at it currently. Looks very nice. I like that there's some examples because I'm a guy with zero run books, you know, and I can put my deploy script into here and write about it. But, you know, just trying to kick the tires, you have the Attoin desktop release. This is actually how you guys release a new version of it? Yep. We run that all the time.

You run that one all the time. Which is like, It's maybe like, hmm, seven or eight steps updated 23 hours ago, so you're still currently working on it. That's always awesome. And then there's also one.

Yeah, we also got one for the CLI as well. That one's not yet open source, but there's mostly automated, like the first 80% of it just runs. Then there's a nice little step of like, go look at this, make sure it's correct,

merge the pool request, and then come back to the runbook. Gotcha. So I'm looking at the Attoen desktop release runbook. And in the upper right, there is a green play button. And in front of me is notes. This runbook is a copy of the runbook that we use at to end, blah, blah, blah. Here's your dependencies, the release process, version bumps.

Like it has a typical kind of a markdown looking documentation with executable blocks in there that will run, I assume, on my local machine. If I hit the execute button, the... That's right. Okay. The upper right hand corner with the play, is that going to run like... the entire script top to bottom kind of a thing yeah that's what it does so it's again

it's meant to be flexible enough that you can pick an individual block to run if you need to or rerun or whatever but then if you've built it to be sequential you can just run the whole thing end to end nice and then I assume it just like stops when certain parts fail because

inevitably somebody else's run book it's going to be like no you don't have this thing installed terminals are the only exception so terminals need to exit in some way and they won't exit themselves. So because it's an interactive terminal, we don't know when the command you've run is done or when what you're trying to do has finished. So you either need to exit the terminal within your script or you need to press stop. And when you say terminals, you're referring to like an interactive thing that's going to go on in here? So we have terminals

and scripts. Terminals, it will run like your terminal emulator just in your goals. So it's going to like block and wait for response. Exactly. Whereas scripts, it's like you just, it's like running bash on something basically right so in this desktop release the first thing i see is just a curl command that's a script right yeah and then this says terminal install cargo bump that looks like it's also a that's a terminal these are terminals so if you run one of them it'll um open a terminal locally and and run the thing gotcha i'm afraid to do that oh look at this oh okay because i can actually stop and i can say no which i'm glad i can because i'm glad i can because i'm going to stop it right there Okay, so terminals are interactive

And then scripts are just going to run And whatever the response of the script Yeah, cool thing with scripts is we can capture the output So if we were to capture the output of a terminal There's like a ton of control codes And various other things going on With a script we can capture the output And that we save in our local template system

So we support Ginger, pretty much And you can use the output of blocks To feed in as the input of other blocks So as an example, you might have a Postgres block and the input for that, you might need a database URI that you can only get by running an AWS Secrets Manager command or like a one password thing. So you can have all of the setup to get you to that point in your runbook, and then you can run the query with the output and the script. Gotcha. Super cool. So these examples are very useful, especially if I'm going to start writing my own because they show you kind of how somebody's really using it. is there going to be or is there currently some sort of like compendium of example like beyond

your guys as official examples like I assume some sort of hub that's like shared coding thing so if you were to go to hubdoratwin.sh slash ellie you can see my profile okay so this is a thing yeah um for the idea I did not ask me to ask this question I didn't tear up on purpose I really did not know if that's a thing yeah um You can currently share runbooks only. Okay. And they only work for using an online workspace. You can mark them as private, public, or unlisted.

I might share a getting started guide or a migration guide or a self-hosting guide for something I'm sharing with the world. Maybe I'll do a build guide for the desktop app. One of the other things we want to share on the hub is actual blocks. So currently you can have saved blocks. Maybe you have something for setting up your dependencies that you do across like 10 different runbooks. you can just save that locally and then import it into various other runbooks. But in the future, you'll also be able to share those via the hub and access other people's blocks to try and kind of just speed up what everyone's doing.

This is very cool. This seems like fertile ground for early adopters to get out there and build out their profile, you know? Is it accessible to everybody at this point? It's just not like indexed. Yeah, it's not indexed. Yeah. Go ahead. How do you do it?

Like, if I wanted to start publishing, what would I do? In the desktop app, when you start it up, it'll often make an account. If you said no, just click your profile on the bottom left and you can register there. And that will get you set up with an account. Okay, you can edit the desktop app. You should be good to go. Gotcha. Yeah, so I did appreciate that.

One of the things I don't appreciate about desktop apps that should just be usable local without any sort of account, is when they still don't tell me I can use them locally without an account. And yours does say, hey, sign up. And then it's like, but if you don't want to, click right here and just use it. And so that shows me that you're a person that I like because I do appreciate that. Just let me use a thing. And then if I want to sign up for a reason that's like having a profile, make it valuable and I'll go ahead and sign up what I want to.

Exactly. I want it to be useful offline. I want it to be useful like open source. And I think one of the big things we're aiming for is like, you know, we might not be around in three years' time. I would very much like to be. However, if we're not, and someone has built out their whole entire workflow on this, it would really suck if they couldn't use it anymore. So it's important that they still can. Yeah. How portable do you think it would be if I was building my run books, assuming the worst? Like, you disappear, the company

disappears, the GitHub repo's gone. Like, I can't run it. You know, I never got the self-hosted thing. Could I get them out relatively easily? It's got to be close to text at the end of the day, right? So if you're using an offline workspace, it's just YAML on your disk. And the format is quite verbose, but a bunch of scripts, and you can pull it all out, and it's fine. What you can also do is you can export Markdown. So it is, we don't really like the fact that there's, there's YAML as our file format. So the end goal will be to use Markdown as the file format. But what you've probably noticed is that the editor is richer than Markdown provides sort of, for sure.

markdown for. So figuring out like a very light extension we can do that lets us encode everything we need to encode but also makes it so that you can still actually edit it in a text editor and read it and various other things. So that's not done yet and that's something I want to do correctly and would actually appreciate input on if anyone has any thoughts. But if you export markdown, you'll see that there is some front matter in the code blocks, which is how we're currently seeing things. Gotcha. Yeah, I think that would definitely be a huge upgrade. grade, we'd get that done. What else you're working on?

What else is in the pipeline? Yeah, so coming really soon is a new runtime. The current runtime is very much like, let's get something that works and see if people like this. And the new runtime is going to be, let's make sure things are really, really robust and flexible, and will allow you to run, run books from the CLI, which is, in my mind, very important

because then it allows you to run them in the CI systems as well. So maybe you have a read-me that's getting set up and you could actually test your read-me. And that would be really cool. Maybe you have a bunch of disaster response runbooks. It's really important that they actually work and you don't find out that they don't work at 3 a.m. when you need them. And if you get things set up right, maybe you could test that on a schedule and some automated system somewhere. I think it's also important just to be able to execute these things without a desktop app if you really don't want to do it. So that's what's coming soon.

So when you say a new runtime, can you unpack that phrase for me? Yeah. And tell me more about what that means. So when you click play on a terminal, there's a bunch that goes on behind the scenes. Currently, the front end makes a call to the back end to ask it to open a pseudo terminal, and then it gets a handle back, and then it starts writing to that with the input you've provided it. That's like a special case. So the front end knows that it's a terminal.

It knows that it has to open a Pty and do X, Y, and Z. what we're trying to do is get it to the point where the front end just says, run this block. And that's it. And that means that the front end doesn't have to be a desktop app. It could be anything. And it also opens the door to a lot more flexibility in how blocks are defined. So we're not there right now. However, I would love for people to be able to write their own blocks, their own integrations.

Whether these are backed by a shell command or some big set of code doesn't really matter. But right now it's very much like every block works, but it's like a nice sort of combined effort between the front end and the back end. And we'd like it to be the front end is as minimal as possible. It's more minimal, does less heavy lifting so that a different terminal could call a run book and run it from there. Is that going to require you to first figure out a more permanent serialization format or you already have that work?

No, so the serialization is, is, there's like the in-memory format and then the on-disc format. The on-disc format is the one that's up for change, the in-memory one we're happy with. Okay. Right on. It is open source. Is it open contribution? How do you, why do you, when do you, how do you, like, tell me more.

So we accept contributions from anyone. We accept fixes, especially, like quickly, features. This is something I never really planned out with the, with the CLI, because I didn't think anyone would care when I first released that. We never really thought about how to accept future requests from people. And in the early days, I was very much like, oh my God, someone's built something cool, let's merge it and let's go. And towards sort of more recently, it's been, you know, is there something I want to maintain long term? Is this something that people actually want? Or is this just sort of bloat the code for no real reason? For instance, there's been a

poor request open for a really long time that I feel kind of bad about, but someone's added PowerShell support, which is super cool. However, when he first opened the pull request, I haven't seen very many pull requests from the guy. And if he's listening, I really appreciate your work. And thank you very much. However, when he first opened it, I didn't know if he'd stick around. And I made it very clear that I could not maintain a PowerShell integration. It's not something I have any familiarity with. And the dude stuck around for like six months, making fixes to various things, making other PRs. And now it's like, well, I have

trust in your code and I also have trust that when you say you're going to stick around and keep it going, you probably will. So that's also a consideration I never really had originally for jumping back to your original question. Open contribution fixes like anyone fix anything and open a poor request. I'm super grateful and we'll review it as quickly as possible. Features, if there's like an open issue for something and someone really wants it, wants to make the make a be offer it, that's awesome. But I do generally, really prefer an issue before someone makes a PR purely because it really sucks to say no to something someone's put a lot of effort into. Right. It's a lot easier if it's just an issue.

Yeah. There's code behind it. You're like, oh, you spent all this time. Yeah, you spent all this time on it and then that's not something we're going to merge and I'm really sorry. Do you communicate a roadmap or like a place where you're headed because sometimes it's hard to know, like I have a feature request. Obviously, I could just ask. But if I knew there's like, here's our direction, I could at least say if I'm tangential to or not. So a roadmap is on the roadmap. I'm planning on doing it soon. Yeah, a roadmap that includes to create a roadmap.

Yeah, I like that. So soon we'll be writing a ton of issues, realistically. I've got like internal notes and various other things and what needs doing. And now that we're a consort that needs to be made public, the format of the roadmap will probably be mostly GitHub issues just because that's what's accessible to most people and pretty much everyone has a GitHub account. But we will be using the forum and the blog more too. So a lot of the developments so far has been on the forum.

It's generally where we've found discussions live best. GitHub issues, I tend to prefer keeping actionable. Like, you know, there's a clear reason to close one because a PR has been merged or something like that. GitHub discussions never really did it for us. They felt like an afterthought from GitHub, to be honest. Well, came years later. Exactly. So discourse, we host the discourse forum, and that's been a nice place to host discussions.

What about the CLI? Do you consider it mostly done? Is it a major feature requests? Is there a roadmap for that? Or what's the status of the CLI tool? Yeah, there's less of a roadmap, more of a bug fixes I will try and get to as soon as possible. Features. I tend to prefer features a lot of people ask for or that I personally really feel the need for,

which a little bit selfish, but, you know, but it's very much, I would rather see enough demand for a feature before bringing it in, unless it's very, very obvious that it's needed. There's been a lot of, I think recently I saw someone talking about being able to add comments and tags and various other things to commands,

and I think that is useful. However, my thoughts there are that the interface for actually searching them needs to be really good, because there's a little point in adding, organizational and all metadata and not being able to search through it effectively. So I think that's quite a large change and therefore one that unless a lot of our users want it, it's not necessarily worth doing because then we have to maintain it too.

And are those conversations going on in the GitHub issues or is there a separate place for those? Usually GitHub issues, people will make a feature request and then it can be discussed. But yeah, I need to get better at managing those because it's a bit of a mess. fair such as life you know it gets messy and sometimes it stays messy especially when you have a

shiny new object that you're very all your attention to right I mean this thing is a big lift I can tell you put a lot of work into this and you can't you can't spend all your time on the CLI when you're building a desktop app right yeah I think it's definitely

I don't want to neglect the CLI we had one of our users thank us for not neglecting it which was nice because I'm glad people feel that way but the CLI is definitely much more mature we've noticed when I first released it

a lot of the early issues were very this does not work at all on my system because of X, Y, Z and now it's very, this does not work with a very,

very specific set up and very specific set of use cases, which is sort of for us more of a signal of maturity and less of a like, I just broke everything

and more of a, we need to figure out how to integrate with something I'd never considered. Something new or something obscure. Yeah, from my perspective,

I mean, I've just been using it kind of how you built on day one, originally, just ever since. And it just does what it does. And it's mostly invisible. I don't think about it very often. I use it all the time, but without thinking about it.

Like you do good shell tools, right? Like you're like, well, I don't think about LS very often either, but I'm going to use that one all the time as well. We have a lot of people tell us that they didn't realize how valuable it was until they didn't have it. Oh, yeah. That's kind of feel good. Yeah, that's cool.

And who knows, when I get a new machine, maybe I'll finally get the sink to be useful for me. I'm like the only person who doesn't care about syncing things in general. Let me know if you do. It would be cool. And I'm going to try to find a way to use the desktop app. You know, I love your work. I think you put a lot of thought into the way you go about building software. And I think that that's rare and just refreshing.

And it just makes tools that are delightful to use. And I can tell you you put a lot of love into this one, even though it's not exactly right in my daily use wheelhouse. Still look for a reason to go beyond kicking the tires. Yeah, I think. I think in terms of, I hope you do, but I think in terms of users, it's like the CLA has very broad. You know, if you use a terminal, it's probably useful. Whereas the RunBooks app is like maybe less broad use case, but in terms of the actual use, it's much deeper.

Well, for sure. If you're a user of this, it's going to be like part of your daily job, you know, and your team will rely upon it. It'll be very valuable for the people who do use it. So I agree it'll go deep. And these are people who are generally well employed at places. that have complicated infrastructure, and they need tools like these to make their job not miserable all the time, you know?

Exactly, yeah. That's what we've been seeing. Very cool. It was awesome to catch up with you. You've been doing a lot. Anything that we didn't talk about with regard to Ad2N, the CLI, the desktop, San Francisco, motorcycles,

anything else that you think we covered pretty much everything. It's been a good chat. Absolutely. Well, the website at2N.S.H, there you'll find both the desktop app and CLI. Maybe you'll use them both.

Maybe we'll use one of them. Maybe you won't use either one, but you can check them out. They're open source. If you want a good Rust code base to check out and maybe contribute to our listener, I would submit that to you because she makes good software, folks, and she pays close attention to the details

that matter. So check that stuff out. Ellie, thank you so much. I wish you all the best with this new endeavor and definitely keep us in the loop, especially if the self-hosted thing comes out as more things are released and open-sourced. Don't be a stranger. Thank you very much. Great talking to you. So, Ellie pronounces it Atuin, which does sound a bit like Tatooine, which, if there's a bright center to the universe, Tatooine's the planet that's farthest from. But it does have a useful spaceport in most icely, but you'll never find a more wretched hive of scum and villain.

So be cautious, but not with Atuin desktop, which seems like a pretty safe bet. Give it a try and let us know what you think. In the comments, we hang out in Zulip, head to changelog.com slash community to join. It'll cost you exactly $0. Thanks again to our partners at fly.io and to our sponsors of this episode, augmentcode.com and agency.org. That's agn-tc-y.org. And thank you to Breakmaster's cylinder. never find a more mysterious hive of beats and boobs. That's all for now, but we'll talk to you again on Kaizen 21 on Friday.

So you said something about DevOps being dead, or I can't remember exactly what you said, but you have feelings about DevOps, either as a term or as a... As a thing. What is that? I mean, Korean me, if I'm wrong, I thought DevOps was originally meant to be bringing...