Couldn't that be avoided by storing the hash type/version, and silently upgrade on the next successful login (when the password is available briefly in plaintext in the login request)?
It's obvious that he is not a native speaker. Neither am I of course :-)
Congrats on the positive influence and the step forward.
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
31378 smw 20 0 262M 11516 5712 S 0.0 0.6 0:00.00 ./gogs web
I have no idea how well it scales to a large user base, but I feel like this is going to become the go to option for side projects where you just want to share some private code with a friend or two.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
Data from try.gogits.org, Gogs database has 78 users, 41 repositories
I found the README in their Github repo has additional info:
It seems like they intend to manipulate git entirely from Go. Interesting stuff!
If that's still not cheap enough, then you can of course use it on a non-SSD VPS, configure it to use fewer Ruby worker processes and so on.
The only problem I (we) have with GitLab, is that it doesn't cache git trees, so it always fires off a git process to read the repository. (At least when this came up they wasn't open to caching it in Redis. Maybe this changed, or maybe it's available in their Enterprise offering...)
This one looks really interesting and promising. Being open source project is another major bonus.
Which reminds me I have to submit patches to their init script.
Rails is OK, but damn is it a bit of a time suck.
That and I have been hacking the init script to not always use sudo. I generally prefer that root not use sudo, and where I work that bits enforced heavily. So there is a bit of logic there as well to allow for sudo as root or not.
Hopefully I get to it today but if not its not a big deal really.
Anyway, that's a really slick work. Once again Go shines and make that project super easy to install.