Atuin Desktop: Runbooks TUI and API

Ideas
1

Runbooks!
Important topic - thank you for addressing this. Just found out about this by the “console.dev” newsletter.

But to me Atuin Desktop is dead in the water.

Before I explain why, here’s what I have started working on to solve runbooks.

The foundation (which I’m not happy with): Emacs + org-mode.

org-mode allows you to have executable source blocks. One can use its results and pipe them to other source blocks etc. So basically: It probably already can do a lot of the things, that atuin desktop is being designed for (no prometheus though).

runbook-example.org (an org-mode file)

The following block opens kitty with a named socket, sends commands to it and directly executes it.
The combination of kitty + org allows fine grained control over many possible execution scenarios.

But we start with a minimal example here: 

Execute some code, open the terminal and send the commands directly there:

#+begin_src bash :results silent
socket="/tmp/literate.$((RANDOM))"
kitty --detach --hold --directory /etc/pacman.d --listen-on unix:$socket
sleep 0.8
kitty @ --to unix:$socket send-text '
echo "hello to atuin from ${USER}\!"
'
#+end_src

Try it out yourself:

  • Install Doom Emacs
  • Install kitty tty
  • paste this block above into an org file runbook-example.org
  • Cursor in source block: Press Ctrl+c Ctrl+c

Why it’s bad: It requires Emacs + org-mode…
Why it rocks: Text file only, works within terminal 100%

And this is why Atuin Desktop can’t be the solution: it’s not native to the terminal.

Every attempt to get people out of the terminal is the wrong direction. In fact, me as a DevOps and infra guy, I try to get more and more into the terminal. And I’m happily using Atuin already, because it solves real workflow problems. But Atuin Desktop looks like a shiny GUI that is easier to sell than the dry, ole terminal.
The thing is: I can’t recommend to anyone to move their workflow out of their terminals. Not for runbooks, not for anything. Doesn’t matter if it’s a standalone GUI or the web. By creating such a tool you may solve 1 problem, but you create 2 new ones. TUI first, or I’ll pass.

What we actually need:
A literate docs + script execution engine (ideally serverless), which works with every terminal editor. We need what LSP (Language Server Protocol) did, but for “literate scripting” (I propose this as a general term for this field, runbooks are a subgroup of that). Emacs offers this already, but it’s just too incompatible with everything else out there and people won’t switch to it. But a tool that is designed to work with VSCode and Neovim in mind will probably work everywhere for a long, long time. If my time would allow it, I would’ve already started this, but I got other fish to fry.

I obviously don’t know anything about the architecture of Atuin Desktop, but please make it usable without the GUI… I want to interact with it using neovim and probably “neorg”, which aims to be an equivalent of org-mode for neovim. The project struggles with executing code. So this would be an ideal entrypoint to make “atuin runbooks” executable via neovim.

Please don’t sacrifice the 90% of runbooks (actual scripting commands), for the 10%: pretty dashboards.

Happy to talk about this in detail. Runbooks are a very important problem and I don’t understand why they don’t get any love from the industry.

Thank you for getting things started.

1 Like
2

Warp terminal tried to do the best of both worlds: a runbook UI integrated with the terminal app. But no one used it because:

a. The runbooks were stored on warp’s servers, not in your own git repo, because they wanted a way to make people pay.
b. people on your team who preferred a different terminal app were screwed.

I think there is a lesson here for atuin. The issue isn’t the gui - lots of people prefer guis, especially those enterprise folks who pay the bills.

The key issue here is to allow for the runbooks to be stored as plain text locally, so that they can be edited in your favorite editor and stored in git. The cli could be dead simple: “run this step of this runbook”. Fancier stuff could come later.

2 Likes
3

Hey! We pretty much cover this in the last section of the FAQ:

Local + file backed is definitely something that’s in the near future

3 Likes
4

Thanks. But just to reiterate this in a clear way: Editably isn’t my end goal, it’s a prerequisite for my real goal: Having the source of truth be part of the project’s git repo, subject to version control. Everything in one place, with written, auditable, and verifiable history. I won’t ever be using a tool that doesn’t meet these goals.

5

I understand, this is the relevant part from the FAQ

As well as local-only file backed workspaces.

This would mean that you could open a folder as a workspace and use git or whatver you want

6

This is a very good point with “written, auditable, verifiable history” and part of my reasoning in my initial post. And this is actually for the enterprise folks who pay the bills. As technical project lead I often introduced tools to the whole team and atuin has the opportunity here to become the go-to solution for enterprise project documentation runbooks. Right now I use and recommend a lot of justfile tasks, but atuin runbooks could be way better than that.