Fundamental inventions and discoveries are never recognized right away. That's why Nobel prizes are usually awarded for a work done several decades ago. The guys who do revolutionary work in computing right now do exist, we just haven't recognized them yet.
Upgrading to at least the latest minor version (0.7.6y as you say) may indeed be a good idea since there have been some security vulnerabilities discovered e.g.
Yes, but positive feedback for an obviously-doomed project may lead a person to spend a lot of time on it and fail. Of course you never know -- many successful ideas were ridiculed initially. But still, HONEST feedback beats see-everything-through-rose-colored-glasses feedback any time.
In other words, you want to hire in places where there's a large pool of good developers, but few employers competing for them. Am I following you now?:)
Actually I disagree about your "cheap talent" remark. When you are building a scalable startup, looking for cheap labor is not a good idea since it's a part of "fixed cost" you have. Moreover, you don't need that many developers nowadays to build a startup. You only need a couple really good developers, and you want to either pay them really well or have them as your co-founders. (disclaimer: I'm a programmer myself).
Good explanation of benefits of being in a startup hub. However, are there advantages to being OUTSIDE a hub? I can think of at least two:
* Living and working outside a startup hub, you are more likely to encounter a problem nobody else has worked on before. In startup hubs, you have large number of startups working on small number of similar problems, while large chunk of profitable opportunities remain untapped. Why? Typical startup people don't encounter these problems. They are not talked about on startup blogs and you won't encounter that problem walking down University Ave in Palo Alto. In many cases, these opportunities are taken by old school, dinosaurs-like software firms who overcharge customers for their crappy software.
* Living outside a startup hub, you are exposed to users who are a good sample of the general population. This is not true for startup hubs, where users a lot more tech-savvy. While it seems at first that being surrounded by tech-savvy users is a good thing, this in fact may be a problem because building your startup based on feedback from these users may steer you in the wrong direction. You end up with couple of thousand "early adopters" who are enthusiastic about your product, but you are not able to expand further because your product just doesn't resonate with a true average user. On the other hand, if you can get a true average user to be your early adopter, the feedback you get from them will help you make a product which is attractive to a large number of users.
Of course, hubs are way overrepresented in the past success stories. However, more startups are started in the hubs, so it's not clear how actual success rates compare. I would love to see some stats for that.
That kind of reasoning kept me away from taking the leap, but now I realize how flawed that kind of logic is. Yes, most startups fail, but it's not a lottery. The success depends on you. It's sort like saying "only 25% of students end up graduating from college, therefore going to college is a bad idea."
> most people that earn a few million rarely retire after that
If you give a few million to random person, 99% chance he/she will retire. However, people who EARN few million rarely retire. I imagine that's precisely the difference between those who make it and those who don't.
This could be used in video call centers in the future. Image you make a video call to your bank, and a blonde girl appears on the screen. In reality, however, you are talking to a dude in India. However, this would also require "voice substitution."
From my experience, it's not "over-abstraction" per se which is causing performance issues. Rather, it's that people who work at the upper levels of abstraction don't understand how layers below work. E.g. web-developer not understanding what SQL their ORM library generates and how database execute that SQL. Abstractions are supposed to hide details at certain level. However, in practice you still need to understand how things work at lower level, as Joel Spolsky's famous Law of Leaky Abstractions states.
I've seen that problem frequently in the world of enterprise software, where you often have many layers developed by different groups of developers. Developers at level N treat level N-1 as black box. This often leads to performance issues.
This could actually be used to create a "bionic UI." Image Google Maps projected into your eye, as you walk around unfamiliar neighborhood. Hungry? With a blink of an eye you pull up Yelp reviews for nearby restaurants. Want your friends to see that tasty-looking dish? Double-blink and the picture is on facebook.
Being both a carnivore and a big consumer electronics junkie I can relate to your argument. I was mostly answering to parent poster's comment about people starving. However I'm a big believer in technology being able to overcome that kinds of limits. Here's an excellent essay illustrating how 15 billion people could be supported at the level of American living standards:
http://www-formal.stanford.edu/jmc/progress/index.html
(As a nice bonus, this is written by John McCarthy, the inventor of LISP).
Almost every case famine during last few decades had to do with some kind of local conflict (e.g. local gangs interfering with delivery of food aid) as opposed to resource shortage. Developed countries produce much more food than they need and then consume it in a very inefficient way. Growing grain and using it to feed livestock as opposed to consuming grain directly is one such example. Earth could comfortably support much large population than we have now.
This is not an easy thing to do, especially if you use EC2 in conjunction with EBS volumes, which is typical setup. EBS volumes are created in a particular availability zone ("facility") and can only be accessed from the same zone. Therefore you not only need to distribute computing resources but also data, which is significantly harder. So even distributing across multiple Amazon data centers is not that simple. To distribute across different cloud providers you would have to rewrite large chucks of code for each provider or come up with some way to "abstract away" cloud providers. Either way it would be nightmare to manage and is likely not worth it for a typical startup. But yes, this CAN be done.