ellieh

absolutely!

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?

I agree! We're definitely not trying to avoid them as users haha, I can certainly see how it would be useful. There's so much automation that just can't fit into a strict schema, and always needs a human or customization for 10% of it

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

It's aimed at replacing developer docs realistically - anything where you're explaining how to run or query things.

BUT it does also make a nice environment for rich text, with markdown support, so can easily replace internal docs in general

big fan <3

copy-paste of another comment but I think it answers everything here! The only addition I'll add is that if you copy-paste into another Atuin instance, the richness is preserved. If you copy paste to anything else, it'll be pasted as markdown.

---

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!

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!

Mostly - we have ssh blocks that cause the subsequent shell and terminals blocks to run remotely

We don’t yet support full remote execution, but should do soon!

Huge fan of gradual automation

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 ;)

Yes exactly! I have so many systems both personally + professionally, and Desktop has made it so much easier to maintain and work with them all

Let us know if you try it and have any feedback or questions at all

Hello! Atuin maintainer here

Happy to answer any questions

(Hi, author here!)

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

I don't mean to be rude but this has been the case since the project first started in 2021. You have always had to sign in to sync anything at all

It's always been opt-in, or "opt-out by default".

Atuin was until it was bumped to page 2/3 and beyond :(

It is configurable!

And also the default is now to use 40 lines, not the alt screen (has its own drawbacks)

You can set “inline_height”

https://docs.atuin.sh/guide/basic-usage/#inline-window

Atuin stores much more context than ctrl-r does - exit codes, command duration and directory, etc

Also has functions for filtering command search by directory

Being backed by SQLite tends to mean your history is more durable + is properly saved across shells too

The main thing would be opt-in syncing, and I think we might store a little more context than fish does in their SQLite!

Otherwise consistency is nice if you use a few setups

You already have it

Nothing syncs without you registering an account or logging in

You actually have to go and register an account or log in for sync to happen at all

Otherwise it’s offline, by default, right after install

All user data is e2e encrypted, but yes self-hosting might make you feel better about where your data lives

We wrote some more about it here: https://blog.atuin.sh/new-encryption/

(dev here!) thank you so much! I love to hear things like this <3

our sync is opt-in + optional, e2e encrypted, and self-hostable.

if that's not enough, you can disable all network features via a feature flag at compile time

if you don't care for sync, there are a bunch of other projects doing this (and supporting several shells), eg:

- mcfly: https://github.com/cantino/mcfly

- resh: https://github.com/curusarn/resh

Sounds similar!

Shoot me an email if you fancy trying it

Ellie at Atuin dot sh

You can literally just ask it to not write too many comments, describe the kind of comments you want, and give a couple of examples. Save that in rules or whatever. And it's solved for the future :)

> nb: system web views are very inconsistent

we've found they're generally ok between mac/windows, with some issues on Linux. Nothing insurmountable, however.

Anything super complex (terminals, charts) we can render with canvas or webgl anyway

agreed - we actually have a dependency system in the works too!

you can define + declare ordering with dependency specification on the edges of the graph (ie A must run before B, but B can run as often as you'd like within 10 mins of A)

Thanks! We're using Tauri (https://v2.tauri.app/) on the client, and Elixir + Phoenix (with a little bit of Rust via Rustler) on the server

Tauri means we can reuse a lot of the Rust we already have, easily do the systems stuff we need, and have something light + fast. Elixir has been awesome and makes a realtime sync backend easier

Not currently open source while it's under heavy early development, we will be opening up the desktop app later on

Sync is optional*, end to end encrypted, and you can self host the server so you don't really need to trust anything if you don't want to

*: nothing syncs if you don't register, and you can even compile a version with the sync code flagged out if you REALLY don't want to trust anything

Came to the comments to say this. As I've been learning Elixir + LiveView, I've been consistently surprised at the amount you get for "free"

(hey! atuin maintainer here!)

Thank you for the kind words! Glad you find Atuin useful!

> It’s pretty easy to run your own sync server if you’re not big on send your commands to some random server somewhere.

We always intended to keep it easy to run a sync server! But also fwiw, sync is e2e encrypted, so we can't actually see anyone's commands

I've spent a bunch of money on Sonos products in the past, and this app update basically killed it for me. Hopefully they can recover what they once had.