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.