Blockchains are meant to be eternal. Check out Arweave arweave.org. Might fit your use case.
105 karma · joined July 1, 2010
Google doesn't share or sell your information. This is a common misunderstanding. No advertiser can identify you individually. Rather you're an anonymous part of a large group with certain characteristics specified by the advertiser. Google also allows you to opt out of targeted advertising. Finally, Google's philosophy is that it will release PII data of its users over Google's dead body.
In comparison, ISPs can share "precise geo-location, financial information, health information, children’s information, social security numbers, web browsing history, app usage history and the content of communications”.
There are powerful financial interests at work here. I think this is going to be a common way to swerve the conversation away from the heart of the issue.
Disclaimer: used to work at Google.
Are you using roomscale? It wasn't clear from your comparison. It's the biggest difference that matters between Vive and Oculus. Roomscale is fundamentally a superior experience. Until Oculus has a generally available implementation of it, Vive is at a different level above Oculus.
Alternatively, a quantitative measure of effectiveness is the company's revenue or net income per employee. For 2015, that's $1.2M / Googler or $264K / Googler, respectively.
Transporting and then returning humans to a "distant" destination will be a worthy milestone that will teach us a lot. We have to start somewhere.
Perhaps you're right: maybe we can more quickly achieve distribution of humanity by solely focusing on robotic exploration. But I just wanted to point out that satisfying science fiction fanboys isn't the only reason to travel to Mars.
Bing appears to be using a non-scalable approach for Bird's Eye view. E.g., Seattle downtown contains a few 3d buildings in a very confined area. It might even be manually modeled.
What Google has announced is impressive because it is automated and scalable. Small demos are great and all (e.g. C3) but qualitatively different from getting something like this deployed into the real world.
Disclaimer: I work at Google.
E.g., suppose Facebook's equity takes a significant decline in value on the public market: employees become unhappy as the equity component of their compensation declines; Facebook's ability to make large acquisitions becomes more expenseive when its stock is worth less; and its ability to raise capital diminshes because it's more expensive to borrow exactly because their financials aren't as good, according to their stock price.
I personally believe that the long-term goals of investors and founders are very well-aligned. I believe that the common statment by founders nowadays, that they are building a company not for their investors but for their users, will produce the long-term financial results that investors want. It's the short-term goals of investors that conflict with that.
In short, equity isn't this isolated thing that can be happily ignored. It's tied to everything.
Bottom line, the article is talking about growth in revenue and income. The article outlines that growth can come by two ways: growth in the number of users and the growth in $/user. It claims that the former has little upside because of how large Facebook already is. It raises questions about the latter.
Clearly, a benefit is that you can move fast. You don't need permissions from someone half a building away to do something. You don't need to touch code that needs another team's approval. There are no committees that decides on global rules. Your team decides on your team's rules.
Like a shared nothing architecture, there's very little that is shared between teams. Teams are often connected only via their service interfaces. Not much else beyond common tooling.
But even their tooling reflects decoupling. Every tool follows the self-service model ("YOU do what you WANT to do with YOUR stuff"). Their deployment system (named Apollo, mentioned in the slides) and their build system, and their many other tooling, all reflect this model.
Cons. What happens is that you might be reinventing the wheel at Amazon. Often. Code reuse is very low across teams. So there's no shared cost of ownership at Amazon, more often than not. It's the complete opposite at Google w.r.t. code reuse. There are many very high-quality libraries at Google that are designed to be shared. Guava (the Java library) is a great example.
Another con. You may not know what you're doing. But as a team you will still build a rickety solution that gets you to a working solution. This is the result of giving a team complete ownership: they'll build what they know with what they have. Amazon is slowly correcting some of these problems by having teams own specific Hard Problems. A good example is storage systems.
And a lack of consistency is a common issue across Amazon. Code quality and conventions fluctuate wildly across teams.
Overall, Amazon has figured out how to decouple things very well.
As far as ADitS goes: it's the epic arc of human civilization over time and also the clash of different civilizations that really brings out the hidden assumptions we make based on our human condition.
Especially memorable was the history of the Qeng Ho, and how the customer planets die off as civilizations rise and fall.
So many cool things going on here. And so many open positions. Remote: probably not, but who knows.