Atuin Desktop: Runbooks That Run – Now Open Source
blog.atuin.sh
blog.atuin.sh
Let us know if you try it and have any feedback or questions at all
I can’t guarantee we never will, but I am only interested in such things if they are genuinely useful
If we won’t use it internally, and no significant % of users will, then it won’t happen
Despite the goal of homogenizing each clients environment to simplify support, there will always be uniqueness amongst them. Having documentation that can be collaboratively edited, versioned, that is also runnable to perform management tasks would be a HUGE deal.
I understand this isn't the target audience, but its exciting to imagine the possibilities of other uses.
We're aiming to be flexible enough, so that if you can do it in a terminal then you can _also_ do it with a runbook
Here's an article on how to accomplish this: https://howardism.org/Technical/Emacs/literate-devops.html
It’s definitely baked into the approach here. You could just write a bullet point list of what needs doing. Then maybe sprinkle some blocks on top so the user can do things faster. Then in the end, work towards the whole thing being automated
No all or nothing, no YAML needed ;)
If I press run at the top, then it doesn't stop for me to do 3 before executing 4. Should I run each step individually for this usecase? Will changing the directory in step 1 apply to steps 2 and 4 if I don't hit run at the top?
Last week I was trying to `find` something in some directories, failed, `cd`d to my home directory and instinctively hit up-arrow+return to run the search again. At some time prior to this, Atuin had stopped recording new entries without my notice. Want to guess the last entry that Atuin did record?
Go on. Guess.
Yep.
`rm -rf *`
In my home directory.
Luckily I have backups of everything important and didn't actually lose anything, and I'm mainly posting this here as a funny anecdote. But - still - after getting myself set up again I have yet to reinstall Atuin.
Behavior of any system should be just one of: 1. Fully determinate 2. Have enough latency before confirmation (for example, block input for 1 second after displaying a command)
This should apply to history, any fuzzy searching, autocomplete etc
You could also make a mistake by executing command #101 instead of #102.
1) This is why you never type rm -rf * but the absolute path.
2) Furthermore, the command flag -f implies never prompt (taken from a recent GNU coreutils man page):
"-f, --force ignore nonexistent files and arguments, never prompt"
3) This is merely unlinking; the data is still there, not overwritten.
4) You should have backups of your homedir. A filesystem with versioning like ZFS could be of help here, too.
5) Agree with you and add a blacklist to the history, with rm being a primary contender.
6) Instead of rm, use a system where you move files into a trash bin (ie. abstract the unlinking in a user-friendly interface such as the trash bin or recycle bin concept). Examples: https://github.com/imnyang/tsh https://github.com/Byron/trash-rs
Now, I think you could do #5 or #6 (and add `mv` and `dd` as well, but where does the list end?), but I think #1 (using the absolute path) is the easiest to avoid the worst PEBCAK.
It requires you to think about that when doing it ... but, well... I dunno. I really don't ever write `rm -rf *` even in that state of mind. That's like the most evil command one can type into a machine! Who knows what it will do!
Glad to see that this is now open from closed beta!
I would pay you guys for E2EE syncing, but I think it’s free at the moment. Charge me!
It's noob friendly. Even the installation process. No need to manage python. Just use the app.
> Besides this seemingly needs an account with Atuin to work.
You don't need an account to use it.
we already support execution of script + terminal blocks over SSH, but want much tighter integration. Parallel execution is certainly a part of that too. anything else you'd want to see?
so you run like this:
./run setup
./run
There are no dependencies to run the script, and if any of the commands needed dependencies you could just put them in setup and call setup from a commmand.
You could keep the content of your bash functions close to intact by adding the ".ONESHELL:" target (and some \$).
There's an example here: https://github.com/atuinsh/desktop/blob/8ebed35d7efe68a92363...
I'm aware this isn't ideal, and longer term we want something that looks much more like markdown. A key requirement for us here is that it's easy + convenient to type - just like normal markdown - so putting everything as a code block annotation isn't ideal.
The current sketch of what that could be looks like this: https://forum.atuin.sh/t/desktop-devlog-markdown-vim-local-f...
Would love to know if you have any thoughts!
Also, I noticed there's only 60+ Atuin sponsors (at Github), so added myself. Been using Atuin for some while now. Hopefully their work is sustainable.
On first glance, I kind of like it - bash scripts are often ideal due to being largely universal and can minimize dependancies.
I find and if this can be an in between to let anyone access configs, or processes, that might be bearable.
I love Warp Notebooks. And I'm definitely interested in At in Desktop, although, if they are run books, the naming isn't quite matching up for me.
#NamingIsHard
Happy to answer any questions
We don’t yet support full remote execution, but should do soon!
---
The runbook files are just YAML (for now). They're more verbose than I'd like, but do convey a lot of information - both rich text and executable.
There's an example here: https://github.com/atuinsh/desktop/blob/8ebed35d7efe68a92363...
I'm aware this isn't ideal, and longer term we want something that looks much more like markdown. A key requirement for us here is that it's easy + convenient to type - just like normal markdown - so putting everything as a code block annotation isn't ideal.
The current sketch of what that could be looks like this: https://forum.atuin.sh/t/desktop-devlog-markdown-vim-local-f...
Would love to know if you have any thoughts!
BUT it does also make a nice environment for rich text, with markdown support, so can easily replace internal docs in general
In my infrastructure repo the README and playbook files have executable org babel scripts for common debugging activities.