Syncing shell history between machines seems like an incredibly bad idea considering how many commands are specific to one host and not having all the commands from other hosts in the history makes it so much easier to find them again in the history. Maybe I am thinking about this too much from a cross-platform and server viewpoint though.
Open Source
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon from opensource.org, but we are not affiliated with them.
You can though search, hit TAB, and then do edits to the line before executing. That is pretty handy if it is something complex across a few machines with a specific change.
Yeah, but lets say I have two servers, one hosts matomo.foo.com and the other hosts matomo.bar.com and I want to update each of those for the second time (the commands are already in the history from last time), with sync I would have to pay much more attention to get the correct commands from the history when I recall the commands for upgrading the database in the correct vhost dir for each (some php matomo.php core:upgrade or similar invocation using a script in the vhost dir), especially when it is mixed in with commands from 50 other servers.
Or lets say I run some dangerous command on the dev server (DROP DATABASE), without sync I can never accidentally use it from the history on the live server.
I don’t have a clue what any of what that means but I’m a big discworld fan so I love the choice of name.
Does sqlite read-only access still work when the disk is full? Would be bad if your history tool prevented shell access when you need to delete something if your disk fills up. Also not sure how fsynced access might slow down debugging of I/O starvation issues (when you want your shell to run from memory mostly).
I think a lot of other OS things are going to break when a disc gets full... But you can also delete history within Atuin.
The point was more if atuin breaks your shell under those circumstances so you can not fix the full disk. Sqlite usually writes some transaction file before it does anything, doesn't it?
But like most other things you'd chroot in and disable it? I think though whatever fills up your disk is probably going to prevent a proper boot up.
Usually apart from potentially a reboot afterwards to make sure all services are running normally again a filled up disk doesn't require a reboot.
Stumbled across some self-hosted hacks online but hopefully someone does a PR to add instructions to their GH wiki.
Which theme is that?
Atuin only has styles really but if you mean the bash prompt, I'm using Starship prompt.
Is it fast?
Fast to open, search, sync compared to? To answer generally, though - no lags or long waiting for anything to happen.
How are y’all planning to sustain the server?
It can be self-hosted as well so that server is not essential to the service...
Yes, but you still have an official server to maintain.
In what way though? If you're self-hosting you just keep your server online. It does not need that central server at all to operate. Even if there are no updates it keeps running.
I didn't mean that all servers would require the central server lol. Unless I'm mistaken, the default is still the official server, and that server is still going to have to handle a ton of requests from people, which requires money to maintain.
Ah got you, it is just text though so the syncing is pretty quick and light. I'd say way less than any site hosting images and videos. The default is no sync, so users need to set that up to sync too. It attempts to do smart sync between successful syncs.