Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I quit my job to work full time on my open source project

ellie.wtf

Post reply on HN
Print view View original

51–60 of 190 posts

Re: I quit my job to work full time on my open source project

#51

Post by drbaba »

the_arun wrote: post #30

What 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.

> If you are running servers passing passwords as command line arguments in that device, they have all that.

I make a point out of never doing that. It’s way too easy to accidentally expose things. For instance, doing a live demo with an audience, and using Ctrl-R out of muscle memory? Suddenly you flashed your password in front of everyone.

Generally, I’d recommend using a tool like Unix `pass` or your default OS keyring to store your secrets, then you can run `command1 --password=$(command2)` to feed a password from one command to another. If I really have to type something sensitive, I prefix the whole shell command with a space, which in many shells can be configured to mean that it doesn’t enter history. If you do so by accident, the shell history file can be edited in vim.

Re: I quit my job to work full time on my open source project

#52

Post by drbaba »

extheat wrote: post #49
euos wrote: post #45

Earlier quoted context omitted.

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 s…

For that example: Any reason the server doesn’t just have an SSH server? Then you can use `git clone` in the “usual way”, using SSH certificate authentication.

Re: I quit my job to work full time on my open source project

#53

Post by CraigJPerry »

cuu508 wrote: post #44
Brian_K_White wrote: post #36

Earlier quoted context omitted.

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.

You can tell your shell to ignore commands started with a space

    HISTCONTROL=ignorespace
Or you can use HISTIGNORE to always ignore specific patterns.

Re: I quit my job to work full time on my open source project

#54

Post by neurostimulant »

ctur wrote: post #27

While 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…

CouchDB might be useful for this scenario due to its multi-master support so devices can sync to each other without using a centralized database. It's also very performant, though if you put gigabytes of data into it, it'll also consume gigabytes of RAM.

Re: I quit my job to work full time on my open source project

#55

Post by cimnine »

motoxpro wrote: post #43

What 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.

I often hit CTRL-R to reload a services config. I press `CTRL+R`, enter `reload`, and continue to hit `CTRL+R` until the right service appears. Enter. Done. Usually way quicker, especially when switching between distros. As one calls it httpd and one apache, once it's systemd and once it's and init script, and so on.

Re: I quit my job to work full time on my open source project

#56

Post by CraigJPerry »

motoxpro wrote: post #43

What 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.

I feel like I get a decent return on mining historical command usage for new (single keystroke?) aliases to setup, the most useful ones change over time for me.

Another use case I feel pays off is complicated one-liners where I need to do something similar but not quite the same again - good starting time saver. This depends on you being a mostly cli kinda person obviously, if you instinctively reach for excel over awk then ymmv.

Re: I quit my job to work full time on my open source project

#57

Post by Gee8r9 »

ilaksh wrote: post #34

Has anyone who uses fish shell compared that to Atuin? I suspect that having my entire shell history accessible might not really be necessary.

Fish has smoother usability, autocompletion and search. It is useful on fresh machine in vanilla configuration. Installing bash plugins is not always possible. Installing some sync plugin on sensitive server is nono!

Also my biggest problem with bash, sometimes it does not keep part of recent history, if bash process gets killed. Fish does not have this problem.

I usually keep useful commands in notes, and sync my notes instead.

Re: I quit my job to work full time on my open source project

#58

Post by rcpt »

motoxpro wrote: post #43

What 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.

I don't really know how to use awk and ctrl-r is faster than going back to stackoverflow to figure out what I did last time

Re: I quit my job to work full time on my open source project

#59

Post by QuantumG »

ram_rar wrote: post #50

I'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?

Freelancers typically make money by coding up solutions, leaning heavily on open-source, for individual clients (as opposed to mass-market software) or other forms of consulting. Sometimes they will become the caretaker of one or more "projects" that multiple clients rely on. That maintenance is billable. It's not uncommon for contract programmers to become small businesses. If they think they can get support from the community, open-source becomes the best option.

Re: I quit my job to work full time on my open source project

#60

Post by lanza »

Brian_K_White wrote: post #36
lanza wrote: post #17

I 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…

> 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.

That's absurdly naive to think the simplistic constraints of your own workflow is a general rule.

Post reply on HN