Why does it have kubernetes?
I quit my job to work full time on my open source project
41–50 of 190 posts
Re: I quit my job to work full time on my open source project
#42I love the idea of Atuin but it's just way too slow with large history files. I've synced my history on my own for the past decade and have like 170k lines and the history search the ctrl-r search just crawls. I don't need most of the history, but there's 0 chance in hell I'm auditing that many lines to decide what I need and what I don't need.
You don't need any of it. History is useful enough to exist as a feature, I up-arrow routinely, but it doesn't actually matter when it doesn't exist. I find the idea of going out of your way to preserve and migrate years of shell history and make it searchable in a db about like: You have a problem that water is flooding your kitchen floor. Normally you deal with a spill with a mop or towels. There is now too much wa…
I use those ! Bash history features all the time. I.e. !?some_test to just rerun a test case I ran several months ago. I don’t need to sync histories between PCs (they are different enough) but history is important.
Re: I quit my job to work full time on my open source project
#43What should I be using shell history for? I've never wanted to go back in my history but obviously people are getting a lot of value from it.
Re: I quit my job to work full time on my open source project
#44I love the idea of Atuin but it's just way too slow with large history files. I've synced my history on my own for the past decade and have like 170k lines and the history search the ctrl-r search just crawls. I don't need most of the history, but there's 0 chance in hell I'm auditing that many lines to decide what I need and what I don't need.
You don't need any of it. History is useful enough to exist as a feature, I up-arrow routinely, but it doesn't actually matter when it doesn't exist. I find the idea of going out of your way to preserve and migrate years of shell history and make it searchable in a db about like: You have a problem that water is flooding your kitchen floor. Normally you deal with a spill with a mop or towels. There is now too much wa…
History can also contain potentially sensitive things like hostnames of non-public systems, usernames, filenames, URLs. I would not want that stuff to hang around indefinitely.
Re: I quit my job to work full time on my open source project
#45What is the security of this? 1. If someone steals my laptop & breaks in, can they get access to all my history 2. After breaking, if they run `atuin key` will get them the key for my history which they can use from any device (if they know the userid) 3. If you are running servers passing passwords as command line arguments in that device, they have all that.
What do you have in the history that’s sensitive? Keys, passwords should not be in shell history anyways (e.g. I delete them from bash history if I enter by mistake)
Re: I quit my job to work full time on my open source project
#46What should I be using shell history for? I've never wanted to go back in my history but obviously people are getting a lot of value from it.
[dead]
Re: I quit my job to work full time on my open source project
#47What should I be using shell history for? I've never wanted to go back in my history but obviously people are getting a lot of value from it.
Here are some of my often use cases: Long kunernetes commands, or ssh into an ip you don’t have remembered, curl commands when testing an api. Anything on the CLI that is long and either hard to remember or just annoying to type.
Re: I quit my job to work full time on my open source project
#48While I doubt I'd quit my day job for it, over the past couple of years I've been poking at my own database-backed shell history. The key requirements for me were that it be extremely fast and that it support syncing across multiple systems. The former is easy(ish); the latter is trickier since I didn't want to provide a hosted service but there aren't easily usable APIs like s3 that are "bring your own wallet" that…
Built something similar (though I've yet to get astound to the frontend for it--vaguely intend to borrow one).
I neither love nor hate it as a sync mechanism, but I ended up satisficing with storing the history in my dotfile repo, treating the sqlite db itself as an install-specific cache, and using sqlite exports with collision-resistant names for avoiding git conflicts.
Re: I quit my job to work full time on my open source project
#49What is the security of this? 1. If someone steals my laptop & breaks in, can they get access to all my history 2. After breaking, if they run `atuin key` will get them the key for my history which they can use from any device (if they know the userid) 3. If you are running servers passing passwords as command line arguments in that device, they have all that.
What do you have in the history that’s sensitive? Keys, passwords should not be in shell history anyways (e.g. I delete them from bash history if I enter by mistake)
I don't think it's that unusual. What comes to mind immediately is it's not unusual for me to clone something from a private git repo, where a username+password would be needed for permissions. In which case it's possible to put in `git clone http://username:password@example.com` or another git command that interacts with remotes. (To be clear the "password" is typically a token and not human generated string, but still functions like a password).
Re: I quit my job to work full time on my open source project
#50I'm curious about the calculus involved in dedicating oneself to a full-time open-source project. Could someone with prior experience share insights on generating income or potential future exits solely through open-source contributions?