This is super cool

I just watched this video: https://youtu.be/WB7qojkkVVU?si=_sqnKlXrblLSwrs8 and there still seems to be nothing that stands out about atuin. I do think it might be easier to work with the data in a database. Personally I don't see a reason to use this service .

As I commented elsewhere, you can:

- Filter by commands run within the current shell session

- Filter by commands run within the current working directory

- Filter by commands run across hosts (as opposed to filtering commands run on your local machine)

- Filter by commands run within the current shell session

- All of the above searching functionality, with nice fuzzy finding support, time stamps, etc.

Before atuin I used zsh's builtin history, with ctrl+r rebound to present that builtin history through the `fzf` fuzzy finding tool, and zsh configured to share history across shells. The deficiencies I found: I couldn't optionally filter by commands _only_ run in the current shell, I couldn't filter by commands run in the current directory (useful for quickly finding commands I often need to re-run for a given project), and I can't search for commands run across hosts.

If you don't find yourself valuing these things, you may find that you have little to gain from using atuin.

Any plan to implement this on macOS or Linux?

I got 90% of this built on Linux (around KDE Wayland) before other interests/priorities took over:

https://github.com/Zetaphor/screendiary/

This seems very very interesting. I'm still learning python so probably can't build on this. But like a cheap mans' version of this would be to take a screenshot every couple of minutes, OCR it and send to it gpt for some kind of processing (or not, just keep it as a log). Right? Or am I missing something?

Yes, that's exactly what's happening here, minus the sending it off to a third-party.

I didn't see the benefit when the OCR content is fully searchable, in addition to not wanting to pay OpenAI to spy on me.

macOS: https://www.rewind.ai/

macOS: https://screenmemory.app/

This is my application, it does not have AI running on top.

I've not very knowledgeable on the process of building a backend API but could someone explain how sending the email's password back in an error log could ever been a good idea?

Obviously, the answer is never (unless it's for _very_ specific testing in a dev only environment).

In this case, it's not that they were sending the password directly for any reason, but instead returning the raw SMTP log from sending the email; which as a byproduct had the password in it due to needing to authenticate with the SMTP server.

Passwords in error logs are only _ever_ good if doing very, very, low level debugging of why logins aren't working right. Even then it's usually enough to just log which auth backends are touched and their result state. However it MIGHT happen if an encoding issue is suspected. Ideally never on a production system.