Bringing Atuin to the Desktop  ## Metadata - Author: [[The Changelog: Software Development, Open Source]] - Full Title: Bringing Atuin to the Desktop - Category: #podcasts - URL: https://share.snipd.com/episode/b8de7a67-f2b4-47b5-b60f-1158eeec7a65 ## Document Notes ## Highlights - **Move To San Francisco And A New Bike** - Ellie recently moved from London to San Francisco and bought a motorcycle four days after relocating. - She rides a 1290 Super Duke and finds the roads and weather more fun for motorcycling. Transcript: Ellie Huxtable I moved to San Francisco. That's been very recent, just like a month ago, but it's been good so far. Jerod Santo 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. Ellie Huxtable All the time. Yeah, still am. I bought one like four days after moving here. ([Time 0:05:08](https://share.snipd.com/snip/49d9361d-b221-48b4-ad92-3c9f0dccebf2)) - **From Commands To Executable Runbooks** - Atuin CLI excels at recording individual shell commands but struggles to capture multi-step workflows and context. - The desktop app fills that gap by letting you document, annotate, and execute executable blocks inside runbooks. Transcript: Ellie Huxtable 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 onboard a new developer? How do I do something that's a long sequence of steps and maybe needs annotations and various other things? The CLI 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 Atom and Desktop's The answer there at least didn't in my opinion. So what it is is it's 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 with its 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 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. ([Time 0:07:08](https://share.snipd.com/snip/8ef19518-8555-4e7d-8baa-8cda4c9bf27d)) - **Make Docs Executable, Not Static** - Embed executable terminal blocks in documentation to keep runbooks live and runnable instead of stale text. - Use those blocks to run commands and annotate steps so documentation and execution live in the same place. Transcript: Ellie Huxtable So we have things like terminal blocks, which are, if you imagine Notion with its 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 a Confluence page that goes stale to something that you can actually run and read in the same place. ([Time 0:08:04](https://share.snipd.com/snip/7014c98c-0f4a-4e76-871d-4243340cffa1)) - **Use System Webviews And Rust Backends** - Build the desktop with native system webviews and Rust backends to get performance and system integration without Electron's size. - Use an offline-first hub for syncing and collaborative features like multi-cursor editing for incident response. Transcript: Ellie Huxtable But we essentially launched a web app locally in Tauri, and it contains an editor called BlockNote, which is a really cool open source project built on top of TipTap and ProseMirror That provides like a block style editor. And we extended that with all of our custom blocks. So to start off with, you're just editing. You have a choice between a local file, which is currently essentially JSON. We're working on that. YAML, sorry, but again, working on that. Or you can use our hub, which you sign up for. You can create an organization or single player, and it provides automatic syncing, offline first, editing, and the idea of that being collaborative style features. Can have multi-cursors with people all zooming around, which we can see being really useful for incidents or helping someone figure something out. ([Time 0:10:50](https://share.snipd.com/snip/aebe7ea0-27f4-4d81-a3a4-d94a32116ede)) - **Bridge Between Docs And Full Automation** - Atuin aims to occupy the middle ground between pure documentation and full automation. - The desktop app supports partial automation so teams can incrementally move from notes to runnable processes. Transcript: Ellie Huxtable My kind of long term vision there, I guess, is that current automation is kind of an all or nothing approach. You start off with, you know, someone might maybe have documented something and that's that 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. ([Time 0:12:02](https://share.snipd.com/snip/bffabaf2-d925-4992-856d-d4036a7954ed)) - **Scale Makes CLI Migrations Risky** - The CLI's hardest problems are scale-related: massive user data means schema changes become risky migrations. - Small mistakes from years ago persist and complicate future changes and recoveries. Transcript: Ellie Huxtable 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 schemas, 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. ([Time 0:19:03](https://share.snipd.com/snip/6791855d-829f-4a2d-b847-a733439f9245)) - **Expect Platform Differences With Tauri** - Prefer Tauri plus Rust for lighter distribution and performance while accepting Linux webview variability. - Expect Mac webviews to be consistent and plan for Linux differences or embed Chromium if needed. Transcript: Ellie Huxtable Generally, very good. There are some issues that the team are aware of and are working on. So firstly, development experience has been really nice. Being able to write Rost has been really good for us, especially we're doing a lot of systemsy stuff. Being able to include all of the libraries we'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 five six seven hundred or whatever electron apps are now um the resource usage is Lighter i don't know if it's necessarily as light as people might say because like you you are still running a web browser it's just not another instance of chrome um right as you proliferate Jerod Santo Tauris you're not going to have multiple chrome me exactly in the background but if you're just going to run one, you're still going to run a full Chrome. Exactly. Yeah. Ellie Huxtable MacOS has been nice because every user is, you know, they're using the same web view that's consistent. It's what we develop on. So it's, it's fine. Linux has been, honestly, I thought it would be worse. So I'm, it's a lot better than I expected that Taur Linux currently uses an old WebKit version, which has some performance problems. I think the performance is when there's a large number of DOM elements. There are several very long GitHub issue threads, if anyone's interested. Luckily for us being mostly okay on most systems, but it's not quite as performant as it could be on Mac OS. 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 like just doing Electron again. ([Time 0:24:53](https://share.snipd.com/snip/2b2a1e05-b4f0-43d8-a3b9-b32c0aa96c79)) - **Open Source Local, Protect Hub Transition** - Keep the desktop app open source but treat the syncing hub separately until you're ready to open-source it. - Offer offline local files so users can keep runbooks usable even if the hosted hub disappears. Transcript: Ellie Huxtable 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. ([Time 0:28:14](https://share.snipd.com/snip/915fb189-c81c-4373-9741-17cb1594900e)) - **Charge Companies, Not Individual Hackers** - Let individuals use open-source tools free and target companies for monetization because organizations gain the most value. - Prioritize creating organization features that justify paid plans over charging hobbyist users. Transcript: Ellie Huxtable Go have fun. And then it's the companies that should be paying. They get a lot out of open source. Jerod Santo 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. Ellie Huxtable Yeah, it's been really good. ([Time 0:34:10](https://share.snipd.com/snip/db16cedc-3559-4443-a82f-ff7ec2092408)) - **Make Runbooks Runnable And Testable** - A robust runtime that can run runbooks outside the desktop enables CI testing and scheduled validation. - Testing runbooks regularly prevents discovering failures only during incidents at 3am. Transcript: Ellie Huxtable 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, robust and flexible and will allow you to run runbooks 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 readme that's getting set up and you could actually test your readme 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 3am when you need them. And if you get things set up right, maybe you could test that on a schedule in 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. ([Time 0:43:49](https://share.snipd.com/snip/8b7d1460-464a-48fd-93df-50326d5f0aa8)) - **Keep Execution In The Runtime, Not Frontend** - Design the runtime so frontends only 'run a block' and keep execution logic backend-centric. - This enables multiple frontends and custom block integrations without duplicating logic. Transcript: Ellie Huxtable 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 backend 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 that's it um 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 is ([Time 0:44:47](https://share.snipd.com/snip/5544a4f1-8ef6-4561-a10c-5769151ce39c)) - **Merge Trust, Not Just Code** - Open-source contributions require trust that maintainers can support a feature long-term. - Ellie gauges contributors' commitment before accepting complex integrations like PowerShell. Transcript: Ellie Huxtable So that's also a consideration I never really had originally. But jumping back to your original question, open contribution, fixes, like anyone fix anything and open a pull request, I'm super grateful and we'll review it as quickly as possible. ([Time 0:47:42](https://share.snipd.com/snip/5a8e30ba-9eaf-48a4-9e9f-a44551fb8e73)) - **Users Notice Value After It's Gone** - Many users reported they didn't realize Atuin's value until it was missing. - The CLI became an invisible productivity tool people use constantly without thinking. Transcript: Ellie Huxtable Have a lot of people tell us that they didn't realize how valuable it was until they didn't have it. Oh, yeah. Jerod Santo That's kind of feel good. Ellie Huxtable Yeah, that's cool. Jerod Santo And who knows, when I get a new machine, maybe I'll finally get the sync to be useful for me. ([Time 0:52:13](https://share.snipd.com/snip/ef95ee0c-5e98-4c45-b006-f3c576e77a0b))