913 karma · joined October 27, 2008
https://blog.engineyard.com/2014/pets-vs-cattle
My summary here would be that both are good, for different things. If I was deploying a personal site or a personal app, I would probably go with a VPS, because it's easier to set up, and can be a lot cheaper. But if scaling or uptime was a concern, I'd want to go the PaaS route. It comes with a few upfront costs (configuration, statelessness, price, etc) but is absolutely worth it in the long term.
RSVP is helpful because it removes the need for saccades, and so reduce fatigue. They also force you to stop subvocalising. As a result, I am able to read at 600 to 700 with high comprehension now. And over 1,000 to 1,200 wpm with enough comprehension to be useful for things I just need the gist of.
1,200 wpm. It's crazy. I never thought it would be possible. But I suspect that if I continue to use RSVP, it will have a profound effect on my life. There is so much stuff I do not read, because I find the normal experience so painful.
Started contributing to this project:
https://github.com/ds300/jetzt
It's the best OSS RSVP tool I have found so far.
But the analogy holds. On any sort of farm (even a vegetable farm) units of production are fungible commodities. And it turns out that this notion of fungibility is very important in post-virtualisation architectures.
https://blogs.apache.org/couchdb/entry/cloudant_and_ibm_our_...
If a project required constant fixing because, say, the code was very bad, then yes, I agree that would be a bad sign. But I was primarily thinking of dependency maintenance.
I took a look at ncurses to see if I could learn anything about their success.
I count 18 contributors in the README file, which is exactly the sort of thing I was thinking about really. Seems like the package has been passed from one maintainer to the next as people's situation changes. This sort of thing is important! If ncurses had met with the same fate as most GitHub repositories, nobody would use it any more. It would be forgotten about.
I took a look through the configure.in file too, and it looks like ncurses has very few dependencies beyond requiring a sane build environment. And I see that ncurses releases once every few years, and has been doing since the 90s. Oh, and the mailing list seems alive and well.
All in all, ncurses seems to be exactly the sort of healthy project I was thinking of. Regular contributions, shared maintenance, very few dependencies, and a predictable release cadence.
The problem arrises when the things your program depends on go away. For example, if you have a project that is written for Ruby 1.8.7, after June of this year, that version will receive no more updates. If there's some particular feature of 1.8.7 that you depend on, or some bug found, or some security vulnerability discovered, users might eventually find themselves in a spot of bother.
The web of dependencies for most projects is bewilderingly complex. The stacks that we write for are moving targets, and unless your software is moving to keep up, eventually there's a good chance that they just wont run any more.
This sort of thinking is why the IETF publishes Internet Drafts as ASCII-only text files. They've limited the dependency chain to ASCII, because they are hoping that isn't going away any time soon.
This is an example of gender stereotyping.
(Not a joke! Fortunately, caught myself before pressing send.)
http://mail-archives.apache.org/mod_mbox/couchdb-dev/201307....
Your footer is just hilarious of course. You claim that you do condone unauthorised access to other people's Facebook accounts, on a site who's only function is to let you make unauthorised access to someone else's Facebook account.