ellieh

6 ms·

31.
by ellieh 1y ago
Yes! Working on that soon, the same runtime can be used elsewhere. Wanted to start with the GUI so we could really make it what we want, but up next 1. TUI for interactive terminal runbooks 2. CLI for hands-off execution, CI, etc
32.
by ellieh 1y ago
Thanks for sharing! Maintainer here, lmk if you have any questions <3
33.
by ellieh 1y ago
we could absolutely plug it into the codemirror linter! thanks for mentioning issue: https://github.com/atuinsh/desktop/issues/47
34.
by ellieh 1y ago
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?
35.
by ellieh 1y ago
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
36.
by ellieh 1y ago
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
37.
by ellieh 1y ago
big fan <3
38.
by ellieh 1y ago
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
39.
by ellieh 1y ago
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/deskt
40.
by ellieh 1y ago
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!
41.
by ellieh 1y ago
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 toward
42.
by ellieh 1y ago
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
43.
by ellieh 1y ago
Hello! Atuin maintainer here Happy to answer any questions
44.
by ellieh 1y ago
(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
45.
by ellieh 1y ago
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".
46.
by ellieh 1y ago
Atuin was until it was bumped to page 2/3 and beyond :(
47.
by ellieh 1y ago
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
48.
by ellieh 1y ago
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 s
49.
by ellieh 1y ago
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
50.
by ellieh 1y ago
You already have it Nothing syncs without you registering an account or logging in
51.
by ellieh 1y ago
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
52.
by ellieh 1y ago
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/
53.
by ellieh 1y ago
(dev here!) thank you so much! I love to hear things like this <3
54.
by ellieh 1y ago
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 t
55.
by ellieh 1y ago
Sounds similar! Shoot me an email if you fancy trying it Ellie at Atuin dot sh
56.
by ellieh 1y ago
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 :)
57.
by ellieh 1y ago
> 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 c
58.
by ellieh 1y ago
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
59.
by ellieh 1y ago
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 syst
60.
by ellieh 2y ago
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 syn

More ›