* This only works with Git. It doesn't look it'd be much work to make it work for all 4.
* This only pins deps you've declared; that set may or may not contain transitive deps. If it's not complete, the transitive deps will be frozen, forever, until you blow them out of your GOPATH.
I should have mentioned that I also have an iPad. I basically use the Kindle as a small paperback replacement, and use the iPad for everything else.
I whip out the Kindle when I want to blow a Saturday breezing through the latest John Sandford cotton candy or awesome-seeming fan fiction, and I read most technical books and my Instapaper backlog on my iPad. So maybe my desired set of Kindle features is smaller than the average Kindle user, or maybe this discussion is proof that I have no idea what the average Kindle user wants.
- I've owned my (4th-gen, non-touch) Kindle for ~9 months, and it has held up just fine. Maybe if/when I break it, I'll wish for more robustness.
- I've never lent books; maybe I should!
- I haven't been without power for long enough to substantially discharge my Kindle's battery yet. I went to Belize for 9 days with it and had power the whole time, although I did more diving than reading ;-)
- Nope, I've never longed for random access. I've flipped through paperbacks before, but that's a feature I can easily live without.
- Nope, I definitely don't miss color. When I want to lay back and feel like I'm reading a little paperback from my neighborhood bookstore, I reach for the Kindle. When I read a textbook and inspect diagrams or want to look at pretty pictures in Flipboard, I grab the iPad.
I'm just weird with tablets though, so this data point may be worthless. I've considered buying a Nexus 7 (or its rumored successor) just to lay in bed and read code, and the official GitHub app for Android is the best tablet code-reading experience I've found.
I mentioned this in a thread the other day; I've yet to see a good use case for hot code reloading. Can you really not drain requests to that host via HAProxy (or similar), and then actually restart the service? The nice thing about that approach is that your choice of service runtime doesn't matter.
That's legit process supervision. Your process may still be running, but be wedged somehow. Monit can perform remediation based on signals other than process status. Naught can't (and shouldn't) do this.
The server that you describe requires 4 moving parts:
True, but our servers are running all of this anyway; you should use the best tool for the job. Instead of rewriting a fraction of logrotate, you should read `man 8 logrotate` and move on to writing code that will help your business. When you deploy an app written using another runtime, are you going to rewrite 10% of logrotate in that language too?
I've never been interested in hot code-swapping; I find it's sufficient to just take that resource out of the pool, give it the new goodies and then boot it up again. I know the Erlang runtime can do this, but I've yet to find a good use case.
As far as std{err,out} redirection, does Node.js have no Unicorn equivalent?
Daemonization (and respawning) should be handled by a process supervisor, like supervisord/Upstart/Monit or whatever. They can do more than just 'this process died, restart it.'
Also, most of this logging code didn't need to be written: