duggan

"Memristive devices could change the standard paradigm of computing by enabling calculations to be performed in the chips where data is stored rather than in a specialized central processing unit. Thus, we anticipate the ability to make more compact and power-efficient computing systems well into the future, even after it is no longer possible to make transistors smaller via the traditional Moore’s Law approach."

– R. Stanley Williams, senior fellow and director, Information and Quantum Systems Lab, HP

"Since our brains are made of memristors, the flood gate is now open for commercialization of computers that would compute like human brains, which is totally different from the von Neumann architecture underpinning all digital computers."

– Leon Chua, professor, Electrical Engineering and Computer Sciences Department, University of California at Berkeley.

http://www.hp.com/hpinfo/newsroom/press/2010/100408xa.html

It just seems odd to go into such depth on transistor density and CPU/memory architectures (and potential future architectures) without mentioning memristors.

I agree that utilization of cloud resources will be an increasingly fundamental component of modern device architecture, but - at the risk of sounding hyperbolic - if memristors live up to the promise, we're talking about supercomputers the size of the human brain*

[1] http://www.physorg.com/news190483253.html

This is an awfully big post on Moore's Law not to include any mention of memristors*

[1] http://www.hpl.hp.com/news/2010/apr-jun/memristor.html

Note: I am obviously not a physicist, so feel free to demolish my fantasy :)

The breadth of options becoming available is fantastic; it's not that long ago that hosting options were:

  * sharing a single physical machine with a group of unknown other customers
  * renting one or more single physical machines with preselected hardware/OS
  * Purchasing your own hardware and co-locating it in a data center
  * Building a data center

I think, if I were building the infrastructure for a company today (which I am helping with, for a lot of companies), I'd definitely eat the additional cost (can be offset quite a bit by reserved instances) and idiosyncrasies (instance degradation, unexpected performance characteristics) of Amazon.

I spent years toiling over hardware quirks, flakey SCSI adapters, power outages, failing or aging machines. If you rent boxes, you're relying on SLAs (if you can get them) and sometimes insane costs for an onsite engineer to fix something you broke (I mucked up a firewall config once on leased dedicated hardware. Don't do that. Ouch.)

There are similar outages with cloud providers, but depending on which rung of the abstraction you're on, (IaaS, PaaS, etc) you might be in a much better position to redeploy your infrastructure elsewhere if it's a real disaster.

The bigger your product/service gets, the more expensive your downtime is (and the more you're spending on engineers to make sure it doesn't go down. Oh, and your hardware has quirks, and your engineers know them - if they leave, they take that knowledge with them).

Of course, there are situations where you'll want to minimize financial outlay, run something that's not a "web app", don't mind getting your hands dirty, willing to risk hardware failures, etc. Hopefully PaaS providers will continue to bridge the gap for most people.

Definitely depends on your usage patterns :)

I'd say there's a combination of factors, the first (and most important) being that Google is good enough for most people.

You'd need to coordinate crawling so as not to turn it into a giant DDoS machine; speed will be an issue due to geo distribution, variable hardware and result sets.

Validity and reliability of the data would also be issues, and would probably require several peers to "agree" to consistency, but in a way that does not allow easy gaming of results.

I suppose they're all solvable, though I think there would have to be a powerful incentive to do so. I imagine it'd be quite pricey too for the individual, though perhaps Gabriel Weinberg* could weigh in there.

[*] http://www.gabrielweinberg.com/

I'd really recommend reading up on the Solr (I notice you mention Solr in your first post) and ElasticSearch projects; these guys, along with Lucene, have collectively solved many of the problems you're investigating.

They're both open source, and (Solr at least) have extensive mailing lists so you can see the sorts of problems people face when building generalized search engines.

And I think he chose his words carefully, he said median, not average. Of course - to paraphrase Greg Wilson[1] - if one were to go further and compare the "best" driver to the "worst" driver, the difference would be to the power of infinity because the worst driver is dead. The comparison is not useful.

I'd love to see some studies on this sort of stuff though.

[1] "Greg Wilson - What We Actually Know About Software Development, and Why We Believe It's True" http://vimeo.com/9270320

Sure, we understand the context, but it's not something English speaking Europeans say to each other :) I'd be hesitant to suggest that alone is the cause, but might be an interesting additional data point.

The example that I was given was clasping your hands together. If you interlock your fingers to clasp your hands now, you'll do it in a particular way, one thumb on top of the other. Now, it's perfectly possible for you to clasp your hands in such a way that the other thumb is on top. It doesn't feel completely natural, but it's possible.

Preferences, depending on your energy level or mood, etc, can alter.

Personally, I use my MBTI result (INTP) as one of many reference points when I find myself getting frustrating for no obvious reason, or just as a way to understand that other people have basic motivations and preferences that can rationally differ wildly from my own.

The moon doesn't stop being closer to the earth simply because you can't see it from a particular point on the Earth.

About the only thing you can say is that if you were to proceed outward on a linear path from the opposite side of the Earth from that which the moon is currently positioned, then you would reach something other than the moon sooner than you would reach the moon.

But that would be saying nothing, really.

A good read.

  Actually, the first bank we ever talked to about @Stripe was Irish.
  They did everything short of laugh.

Disappointing (since I have a small group of useless domains now, .com, .net and .org) but a useful lesson.

I'm sure there's something similar for Linux.

Case-by-case can be painful/time-consuming - I know, it's baked into the ethos of the company I work for - but it has its rewards.

People have more time for a company that has more time for them.

Still worth being aware of if your case isn't quite open-and-shut, or you're planning a quick launch. I feel quite an eejit for letting it happen.

   cnoreabbrev Wq wq
   cnoreabbrev W w

Spending no money at all might either be worse (they've lost more than they earned) or no better (zero sum) than buying the coupon depending on your future intentions.

Or do you mean that you've returned and purchased again from those places?

Book reviews are coming back, eh!

Here's a thought: anyone in a position of "power" is susceptible to this dynamic; if "social" relationships were described as an equation, then power (P) would be inversely proportional to the effort or energy (E) you need to expend to maintain any given social relationship (R),

P = R/E

The more power/authority you wield, the more of a jerk you can be (not should be or are), because the value of the relationship is lopsided - you don't need to spend as much energy on it.

The power an engineer holds is that they are often quite valuable within an organization, and tend to have an easily transferable skill set.

In any case, one shouldn't need to demand respect, one should command it. The difference is that the former is impossible unless you equate fear with respect, the latter is a natural result of the transferability (or other relative metric) of your talent/skill/ability.

One of the most important goals for my "parent" company after we were acquired was to make sure that I (as the first and only employee) was not going to be killing the company if I left to pursue something else or got sick, etc.

So you've effectively got it, it's just that, in a big company, unless you're the CTO or in some other relatively lofty position, the buck probably does not stop with you.

Depends on the company obviously, YMMV, but I think the important takeaway is that "big" companies aren't just larger "small" companies - they're very different entities.

There's an interesting talk from Geoffrey West that (if I recall correctly) is somewhat related to this topic (the scaling of cities vs companies) - http://edge.org/conversation/geoffrey-west

Apologies if I've left you more puzzled than before!

Last year, we built a search service on EC2, which used SQS[1] and SNS[2] as a way of feeding data from our core architecture into the index.

So, user creates/updates/deletes a message, that information gets sent to a particular SNS topic over HTTPS, a subscribed SQS queue receives message, then search index polls the queue.

SQS and SNS are cheap, scalable and highly available, so we thought it was a great system. We knew that messages were going to disappear occasionally, though (network partition, etc), so we had also decided to spend time building a simple API to resolve these issues.

We would occasionally poll the API directly to effectively perform a diff, by storing a hash "fingerprint" of the data with each entry. Fingerprints would be compared, then a full request would be made for any entry which differed.

At some point, we realized that we actually had obsoleted almost the entire SNS/SQS message queuing mechanism by building a system which made API calls inexpensive; so we removed it from the equation.

If you have a situation where a message has to get there (eventually), in our situation at least, it seems an unnecessary extra step.

Would like to hear if anyone else has had a similar (or completely opposite) experience.

[1] http://aws.amazon.com/sqs/

[2] http://aws.amazon.com/sns/