Why I do not want to work at Google (2011)
mail-archive.com
mail-archive.com
Never mind that those oppressive regimes got replaced by...new oppressive regimes.
I beg to differ that is Internet what makes a regime fall in North Africa. What makes regimes fall is people who can't buy food going from 30% to 75% because of inflation of commodities(created by OUR WESTERN central banks).
Probably you think revolution is great, but I have been in Libya and Syria, before and in the wars and it is horrible. A civil war is the worst thing that could happen to a country, Americans could idealize it as they have forgotten what a real war is(fighting against non developed enemies 8000 miles away is not alike seeing your home in flames, your daughter raped or your brothers killed).
I would love to use decentralized tools, but they are so bad. They have lots of features, but they are incredible hard to use.
People will start using decentralized products when they are as easy to configure and install like a mac. Only centralized tools like facebook or Google provide easy of use that my grandpa could use.
In 2011 the new oppressive regimes had not risen yet. Even today the one in Tunisia seems better than the old one. If you are interested in more detail in what I thought about the revolution in Egypt, http://canonical.org/~kragen/egypt-massacre-sotu.html goes into more detail from January 2011, just after #Jan25. The situation in in Egypt is terrible today.
Violent revolutions have a tendency to submerge their revolution in their violence, because violence leads to rule by the most effectively violent. Those are not the people whose rule I want to live under.
I tweeted about this in May 2011, a few months before the decentralization post we're discussing, when the Syrian opposition was still mostly nonviolent:
https://twitter.com/kragen/status/65789586269421568
"@shadihamid Well, it [violent rebellion] hasn't worked out so well for the movement to overthrow Gaddafi so far, has it? Lots more dead than Bahrain or Syria."
Southerners remember what that was like: 150 years ago Yankees were raping and killing their way across the Confederacy. Young folks nowadays have forgotten, but there are plenty of folks still alive who heard about it from their elders. It really wasn't that long ago.
"Plenty"? Care to flesh out your math, here? I'm working under the assumption that newborn babies make horrible first-hand witnesses and (75 years later) equally horrible second-hand listeners, and that not that many of either are going to live to 75 before talking about their knowledge.
It's probably more precise to say: "A lot of people here know a story about it", the same way a lot of Americans know about the Mayflower.
> Southerners remember
I think you're subtly equivocating here. The "remembering" going on is not at all the same kind as, say, "New Yorkers Remember 9/11".
Yeah, this is BS. That was just a Western media "human interest" story.
For one, those heavily into blogging and twitter and the like in a place like Libya or Tunisia, or invariably more affluent than the rest and more westernized (including more friendly to western BS interests). So they make a good subject to showcase as "the voice of country X", when in reality they are nothing like that statistically speaking.
Second, the "middle east and nothern africa" had tons of revolutions and collapses of oppressive regimes, leftist movements, anti-colonial movements and what have you, all throughtout the 20th century without twitter and blogging.
Just because some place like Egypt is the first time a 20-something guy in S.F. heard of revolution in those countries, doesn't mean it's due to "twitter".
I'm gonna get down voted for that, but maybe if there were less nerd-wars in FOSS community and more thinking about real users the Internet would look differently nowadays.
If you rolled back to the 90s you'd also notice AOL were regarded as a giant invincible behemoth in a similar position to Facebook or Google today.
We built the internet. Maybe you've heard of it. We also created TCP, UDP, IP, DNS, email, the Web, Usenet, IRC, Git, BitTorrent, Tor, Bitcoin, and Wikipedia. We killed AOL, CompuServe, Encyclopedia Britannica, Solaris, the Information Superhighway, and the Advanced Intelligent Network. We were only unable to do smartphones because the carriers ruthlessly shut us out, demanding insane amounts of control over handset software and using their regulatory capture of the FCC as leverage, until Apple forced the doors open for us — but on Apple's terms. And we built most of the software that runs Apple, Facebook, and Google, too.
But how can we build new services to replace Facebook and Google on a decentralized basis, like email and the Web? That's a problem with both technical aspects — how can you build a distributed full-text query processor that runs on the machines of volunteers? — and social/business aspects — how can the people who benefit from these services effectively collaborate to get them created and improved? (Kickstarter and the like show a very promising direction for this.)
Those are the problems I want to be working on, not how to persuade Google Drive users to entrust a well-intentioned but unaccountable central authority with all of their family photos.
I just wonder if we need 10 major Linux distros none of which is easy to set up and use to an average user. (sorry, even Ubuntu is still not there)
I am a big believer in open web and it makes me cringe every time I see a new cool technology that uses closed protocols (or rather APIs) as it happens with IoT right now. But it's hard for me to attribute it to anything else than lack of leadership from FOSS community.
>it's hard for me to attribute it to anything else than lack of leadership from FOSS community.
So when it's a consortium of multi-billion dollar tech companies with massive R&D budgets, political connections and marketing dollars, it's FOSS's fault. OK.
I don't think Usenet, email, IRC, Tor, and the web are "quite low-level compared to what average user needs to be able to use it effectively." In fact, I am at a loss as to how your comment is potentially relevant to mine.
I don't remember it that way all. Does anyone else? From what I remember, there was a very heavy consumer demand for the App store, meanwhile Apple was telling everyone just to make web apps. They actively developed WebKit into a cutting-edge, standards-oriented, developer-friendly browser. I don't see how you could say they wanted to "relegate websites to second-class status".
In other words, by 2011 nobody at Apple was telling developers 'web apps instead of native please'.
Meanwhile, in the past years they did effectively cut things like WebGL on iOS because it was a threat to native app performance in the browser. (iOS 8 finally, long overdue, changed this, now that the app store is there to stay.) Or say blocking Nitro on anything but Safari, say Chrome, not a problem for regular websites, but a problem for JS heavy web apps.
The US gov is mostly responsible here, not Google: http://en.wikipedia.org/wiki/Children%27s_Online_Privacy_Pro...
Google isn't paying millions in lobbying for nothing.
No. Just no. 10 year olds probably don't have the resources to run their own hardware, insofar as 10 year olds don't earn money, can't own property (in a legal sense), and are not wholly responsible for their own actions. Therefore, a 10 year old having an account with a 3rd party unbeknownst to the parents is a security / child protection / legal nightmare.
Saying "keeping your account on somebody else's server is mostly responsible" is disingenuous because the 10 year old has to keep their account on somebody else's server.
Edit: clarity
10-year-olds can keep their data on their own server as easily as they can keep their books in their own bedroom in their own house, sleep in their own bed, call their parents on their own cellphone, and edit videos on their own computer. While the 10-year-old may not have legal title to any real estate, it is not therefore necessary for them to live in an institution. They can live with their family.
Hopefully that clarifies my message for anyone else who may have misunderstood it.
> They can live with their family.
Or legal guardian. That's my point. Children probably do need protecting, so their guardians are tasked, legally, with those responsibilities. Therefore, ownership, security, consequences of actions, etc., aren't clear cut when it comes to children.
10 year olds can own property, legally.
The particulars vary by state, but here's a quick glimpse as to the federal perspective: http://www.dol.gov/elaws/faq/esa/flsa/026.htm
And of course one may work for one's self (start a startup) at any age.
First, there's the family (or guardian) unit. Unless you're advising every individual person on Earth to run their own individual computing infrastructure.
Kragen's argument isn't for an atomized Internet, but for a decentralized one. If that means that there are local hubs or clusters that a neighborhood of 10 y.o.s could access and use, it would be a vastly better world than one in which only a handful of giants provided equivalent services.
You're also showing an impressive lack of imagination in terms of what it is to have an online presence. A decentralized structure with a cache-and-forward, high-replication, mesh-net structure could well function from minimal personal investments as a point-of-entry. A smartphone, or even feature phone, could well be sufficient hardware to enter into the system. I'm seeing Android devices priced in the $20-40 range. There are very inexpensive servers which offer similar functionality.
There's another economic class which is comparable in means to your hypothetical 10 year old as well: the vast underclasses of the world, with annual incomes ranging from $200 - $2000/year. Even among these, access to minimal levels of technology is highly sought simply because it hugely reduces the costs, and provides tremendous values, from communications.
Outernet (featured a few times on HN) is one example of an information service which is aimed at this population, with concerns over cost, energy access, censorship, surveillance, and content quality. It's a broadcast mechanism, but with some sort of mesh-net response network, it could well turn into a bidirectional system (there's also investigation of making the service itself bidirection).
I think that was the point in that article.
> and the evidence suggests that it is to that that we owe the collapse of oppressive regimes throughout the Middle East and Northern Africa
actually happen? I mean to say: Sure, oppressive regimes collapsed, but to be replaced with what? Take the 'Arab Spring' countries Tunisia, Libya, Egypt, and Yemen - are they better off for having traded security and stability for (attempted) democracy.
> Google, of course, wants to solve these problems too. But it has a different, less-democratic approach in mind.
No company is a Democracy in the sense of dēmos 'the people' + kratia 'power, rule', where 'the people' are you, me and the next person. Maybe companies are democracies where 'the people' are the shareholders, at least to some extent, for some definitions of 'shareholder'.
Often we see "The Democratisation of x" bandied about as though it has to be a good thing, but I'm left wondering what the term actually means if the consequences are typically a tradeoff between security + stability vs. democracy.
From what I've seen the media has portrayed Twitter, Facebook, YouTube (etc.) as playing a role in the Arab Spring demonstrations, yet these are exactly the sort of 'unaccountable intermediary' you're railing against.
I think the reference to the Arab Spring without qualifying the consequences of the whole scenario from the vantage point of history is dishonest.
Democracy isn't synonymous with Security and Stability, and we should all probably have a long hard think about Security and Stability before we promote disruption.
(Edit: fixed a thing where I'd written the opposite of what I meant).
I agree that companies aren't democratic. I think that's a good reason not to hand our government to companies.
Historically I don't think there is a tradeoff between security and stability versus democracy. http://slatestarcodex.com/2013/10/20/the-anti-reactionary-fa... goes into some detail about the unstable, insecure history of undemocratic governments, specifically to rebut neoreactionaries who are calling for an end to democracy in order to return to an illusory imagined past of security and stability.
Democracies usually don't make very good decisions. They do seem to make many fewer catastrophic decisions than non-democracies, though.
I'm just not sure there's a huge demand for it though; originally we were thinking that people would care about price, but it turns out most companies don't care that they're being fleeced by AWS. If they do care, they're probably using DO.
Anyway, here's a demo of everything working: http://youtu.be/998IYD_WomY It connects a bunch of desktop machines around the Bay Area on different networks (Comcast, Sonic.net) and blends them in with a "dataceter grade" cloud server.
The real problem with decentralization though is that the asymmetric nature of the first (last?) mile makes it really hard to do anything useful with individual nodes. If we all had symmetrical gigE FttH/FttP everything would be a lot more rosy, but so far that's really only been happening in a few places.
I haven't watched your video, though.
I'm just not sure about your economics argument though; convenience usually trumps any kind of economic reason for using a distributed system over a centralized one. This is particularly so with most internet services because the cost for most things always approaches free. I mean, we're reading HN on a website, and not through alt.hackernews, right?
I don't think this is necessarily true. The Internet started out about as decentralized as it gets, but eventually the Internet coalesced around a few core services - first it was AOL and Myspace, now it's Google, Facebook, Twitter, Youtube, etc. And meanwhile, too many decentralized services have fallen by the wayside - anyone still using Diaspora?
Centralized systems offer efficiency and convenience - decentralized systems have more moving parts and thus more friction. This is a hurdle that decentralized systems have to overcome in order to become successful, and they rarely do, sadly.
This guy's rant is really about the need for decentralization. I fully agree with him. But I disagree that decentralization is incompatible with Google's primary business model (regardless if the Internet is decentralized, there will always be ways to do advertising.) In fact Google Wave (http://en.wikipedia.org/wiki/Google_Wave) was a fantastic and radical attempt at decentralizing common use cases such as email, instant messaging, social networking, etc. Unfortunately this project failed to gain traction due to various reasons.
To return to a more decentralized Internet, we need software and network protocols that let people easily host their mail and blog, publish their social pages, and share their vacation pictures, etc, without relying on the cloud but doing it via a device that runs at home. An ideal place to run this software would be your Internet router, as it really is a full-blown computer that is always on, always connected. And, as the router, it conveniently bypasses the issue of masquerading/NATing which is the one reason why non-technical people do not run server software more often. Another advantage is that uploading stuff to your Internet router (eg. sharing pictures) is much, much faster than uploading them to a cloud service (Wifi or Ethernet bandwidth can be 50x-1000x faster than the typical upload bandwidth of a home Internet connection.)
It should all work out of the box with zero configuration. That is the only way the idea can gain traction. Not everybody is a sysadmin, so your grandmother should be able to make it work. Want to enable your mailbox? Just tick the appropriate checkbox on your Internet router as easily as you would sign up for some mail provider. Want to follow the social lives of your friends? Your browser can render your custom Facebook-style wall by pulling posts and pictures feeds directly from your friends' Internet routers.
We already have most of the technologies needed to implement such decentralized features: HTTP with cross-origin resource sharing, SMTP, automatic registration of DNS names to make you discoverable on the net, OpenID authentication, etc. Maybe some other needed bits can be pulled from the Wave protocol.
But the sad thing is that I am not aware of any attempt to implement any of what I described above. Perhaps it is a vision too ahead of its time. Or perhaps it is because there are 2 important problems that are very hard to solve in a fully decentralized way: (1) search, and (2) spam. You can easily search for and find your friend's blog via Google web search because it has an index of the entire web, but how do you provide this level of quality if the search engine is your Internet router? As to spam, you can easily filter email if you are the Gmail team running sophisticated analysis on the billions of emails processed daily because the more data you have the easier you can classify it, but how do you implement this filtering quality on an Internet router that does not have access to such a data set?
Perhaps the solution is to run most of the services in a decentralized way (email, instant messaging, social networking, etc) while at the same time relying on a few central services for some features like search and spam filtering.
Edit: thanks for the pointers to FreedomBox and Sandstorm, I will look into them.
https://freedomboxfoundation.org/
I haven't followed their progress recently, but apparently they had a release back in March.
You've not heard it because it's not making traction - the above link can run on a rpi and achieves most if not all of the goals the freedombox set out to.
The problem here is the economic incentives to do it are low, but the technical barriers to solving this are genuinely getting lower and lower all the time, so at some point it will happen.
Also, the security consequences of such scenario could be an issue. Organisations with huge resources have a hard time with security, how's the average person going to compete with an organised adversary.
We move now into the realm of speculation.
There's still a social/economic question of who pays for storage — presumably someone needs to be able to say "This data is important to me; please don't trust the rest of the Web to keep a copy," or things that nobody happens to read for a few months will be lost. So there's still "hosting". But it might be more like what EBS or Gandi provides than what Amazon EC2 or Rackspace provides.
I think distributed content-named storage (like CCN, Tahoe-LAFS, Git, etc.) solves the "distributed immutable hypertext" problem, but there are still other problems to solve: how to make things mutable (each of these three has a somewhat ad-hoc and application-specific method for this), how to do asynchronous event notification, how to establish contact between previously disconnected parties (unsolicited messages), and so on.
Think about how you'd build applications like blog comments, or email, or Google Search, on top of such a distributed content-named blob store.
Some people just treat some technologies as a "this can fix anything" when really they're well suited to one task.
This is the sort of thinking that suggests using a Git based solution to sync binary files between computers - the thing even the biggest Git fanboy will admit it does poorly - handling of binary files - and someone wants to use it for that specific purpose.
It might actually be more efficient to do a single-version shallow clone than to fetch all the relevant assets with separate HTTP requests. Git already supports shallow clones, and you can already use them to clone things like Github wikis, and now you can even push from them: https://stackoverflow.com/questions/6941889/is-git-clone-dep.... A --depth 1 clone of https://github.com/kragen/500lines is 7 megabytes, although the full history is only barely larger. My phone has 400+ megabytes of RAM.
More promisingly, though, Git blobs are identified by their hashes. That means that if both my home page and your home page use Twitter Bootstrap 2.3.2, your phone only needs to download it once to render both home pages, since it can see from the blob IDs in the Git directory that it already has the relevant blobs. (Assuming it hasn't been optimistically included in the initial message response!) It doesn't have to worry that one of us might be serving up a maliciously-backdoored version in order to steal users' login cookies on the other's site. By the same token, you can accept the blobs from anyone who has a copy, who might be closer to you on the network than the origin server. Especially if, like me, you're in Argentina with a 250ms ping time to the US.
(This assumes you're using something cleverer than the standard git clone protocol, which builds a thin pack including all the objects you lack.)
So git-cloning websites to view them could actually be faster than loading them over HTTP the way we do it now, because it eliminates a lot of the unnecessary security issues that we work around with bandwidth duplication and high latency.
The only upside you actually identified there, is a reduced number of requests, which is already possible by using HTTP Keep Alive and HTTP Pipelining.
1. You can use 10MB of widely-used JavaScript and stock icons on your web page, and the browser will be able to see the page after downloading 100K instead of 10MB. HTTP keepalive and pipelining don't help at all with that.
2. There are no more broken links, so people can link to stuff that isn't hosted on their own server without fear that it will go away next year, or be redirected to more commercially remunerative content, such as linkspam. (This is conditional on them caching a copy on their own server, of course.) HTTP keepalive and pipelining don't help at all with that.
3. Resources can be cached close to you on the network without you having to trust the cache not to feed you corrupted versions of them. (You do have to trust the cache to not report you to the feds for reading an article about how to download Interstellar.) This makes a huge difference in page load time by reducing latency. Again, while HTTP keepalive and pipelining can reduce the multiple of latency, they can't reduce the latency below 2×RTT to the origin server, and practically speaking they're limited to several times that. This is especially important if you're trying to host your personal pages on a high-latency residential internet connection, and/or browsing from a high-latency country.
4. Making every website not just archivable but also forkable enables a new kind of lightweight collaboration. Well, not totally new — I mean, we're doing it now on GitHub and, in a different form, on Wikipedia.
5. Naming web pages by hash rather than by IP address or by a DNS name that maps to an IP address makes it easy to host them on dynamic IP addresses, including with transparent failover when one of them goes down for a while.
#2 is no different than mirroring content, e.g. how fireballed.org works, but over longer time.
#4 collaboration is about working on something together. Every visitor to your site is unlikely to need/want/care about collaborating on it.
#5 You're suggesting an SHA1 hash is easier to remember than a domain name? Seriously?
You ask, "You're suggesting an SHA1 hash is easier to remember than a domain name? Seriously?" Consider that if I seem to be saying something that's obviously ridiculous, even to you, then maybe you've misunderstood what I was saying, as in this case. I'm going to give you the benefit of the doubt and assume that your lack of understanding is genuine, not feigned to give you an excuse to be rude, but you were rude anyway.
I told you that is already happening in practice, without the overhead of Git.
in your example, i would not agree those two things are the same. Clicking a link that goes to a http:// url and clicking a link that goes to the same file via ftp:// i would say are reasonably similar for the end user.
you're right, i didn't read into #5 enough. so for the purposes of "easier dynamic ip hosting" you're suggesting that browsing to a sha1 hash means it can come from any computer that has a copy of it?
but nobody is going to remember hashes. so you need to use dns or similar, so say "foo.com" has a GIT record, the value of which is an sha1 hash.. but then the client needs to find somewhere to get that from... so presumably you're suggesting some kind of peer to peer system for hosting?
and all of that is somehow better than the existing model, where you simply have a DNS server that has an api to update the IP address of an A record quickly?
You've also skipped over a big issue here.. this whole concept relies on a website being nothing more than static files.
It also effectively removes the ability for the author to have any idea at all about how many people view his site.
Git is reasonably good at what it does. It has some flaws but for versioning text based content, and fostering collaborative working amongst developers/authors, its a reasonably good solution.
As a replacement for HTTP web pages, caching proxies, CDNs, parts of DNS? not so much.
Are you also assuming that Git will one day reach a point where everyday web users can use it? Because unless you're using software to abstract away the ways that one normally interacts with Git, I just don't see your average web user going anywhere near it.
If you're cloning the public repo, that still requires someone to host the website -- instead now, they are hosting the whole history of the website (or not -- they could rewrite history and just have the most current version) -- and anyone who wants to view it has to pay the cost (bandwidth/latency) to clone the repo before they can view it.
It's about centralization's bad effects. If there was a way for the bad affects to disappear, there wouldn't be a reason to rant. All things being equal, people prefer centralized utilities like electricity, water, and gas.
Just as it's possible to decentralize the Internet, I don't see why it's impossible to fight the bad effects of centralization. If you see insoluble problems, please feel free to list them here.
> Google is not institutionally opposed to this;
I think he's exactly right. Google does not oppose decentralization, but at the same time, the entire raison d'etre of a company is to centralize something in the form of a profit center. As far as companies go, Google is pretty good, they are not the threat to traditional internet values, but neither can they be its savior.
Like Xanadu? http://en.wikipedia.org/wiki/Project_Xanadu
If so, how would this new initiative succeed where prior attempts failed?
Perhaps the feature set envisioned for Xanadu (e.g. two-way linking, transclusion) was just 54 years too early.
That’s a pretty weak summary. The product didn’t “fail to gain traction”. It pretty much failed to work in a basic way, at all.
It was the broken technical design decisions and broken technical implementation of Google Wave that doomed it to death, not any problem on the users’ side.
Also, anyone who says that Google Wave was decentralized, as implemented, is kidding themselves. That was Google’s marketing hype (and possibly even their eventual goal), but in practice none of the parts that would allow any kind of server support outside of Google were ever actually delivered.
There was an incredible amount of hype for Wave from Google, and initially there was a great deal of excitement from users and developers outside of Google, when it was first announced and when the first users started on it. And then as they let more people in and as time passed, the technical infrastructure was completely unable to scale (either with number of users or with size of individual conversations), and it became apparent that the web client was a buggy mess that would only work with small conversations involving a small number of people, and the servers couldn’t handle rapid adoption.
The semi-technical marketing documents described how it would be open and federated, with an open protocol implementable by anyone, and would use fancy modern algorithms (operational transforms) to handle multi-party updates to documents in real time. As delivered though, the protocol was big proprietary binary blobs wrapped inside the incredibly verbose XML of Jabber/XMPP protocol (most of the features of Jabber were ignored; as far as I can tell it was only chosen as a wrapper to give the protocol an illusion of openness, rather than for any particular technical merits), and instead of doing any kind of fancy diffs or sophisticated operational transforms, instead the entire content of a message was re-sent to every listening client for every keystroke. The Wave web client software was a big ball of spaghetti Java/GWT code which was closed source (maybe they eventually opened it?), and so it was effectively impossible for someone outside of Google to make an interoperable server or client.
https://github.com/processone/android-wave-client
Stale, but it is out there.
(also: WTH is a PHD script?)
Most of this work is in academia for now but as soon as there are business models that work, we expect to see real deployments (beyond the hobbyists).
To change this services using upstream that make money for the pipe providers are required. Otherwise, no upstream.
Freeloading cannot work. Repeat CANNOT. Because you need fellas with highschool educations to look after the fibre and the boxes.
Downstream will remove the boxes and put them into warehouse scale facilities.
So - Haxxors, get yourselves to the internet of things if you wish to see democracy preserved.
Freedom is in peril.
Defend it with all your might.
Summarized as, "Peer-to-peer overlay networks are inefficient on ADSL networks. ADSL networks are almost twice as efficient as SDSL networks. Better alternatives require redesigning the physical layer."
The fact is we rely too much on the cloud to connect two adjacent devices anyway. The whole notion that much of this data has to go upstream at all is the problem.
(Shameless plug) This is what led me to write this: http://montrealrampage.com/king-ludd-19-manifesto-for-a-frie...
Also, I don't get how you get to freeloading - upstream bandwidth is as much part of the product that the customer is paying for as the downstream bandwidth is.
I think we can probably do petabits on single mode fibre bundles now with the right boxes but the trick is the right boxes, which are spensive and take lots of electricity to run. So even if you can pony up for an FTTP roll out then the use cases are going to be constrained by the network architecture that is used to support it.
Now, for most people this is not a problem as the up channel is basically irrelevant in terms of bandwidth in the current consumer internet, but if you are the sort of person who imagines a decentralised and democratic consumer internet which is not mediated by massive supernational companies, or if you are the sort of person who is interested in where the value is captured in the industry value chain I think this does matter.
Sharing other peoples content will not fund a democratic internet even if governments fund and regulate fttp. We need a new class of applications that generate revenue sufficient to pay for the infrastructure that will facilitate them. If we get that then the infrastructure will also facilitate a shift away from the data centre (not it's elimination though as it will be the way that the current usecases are delivered)
If you have any ideas please write them up - before the industry dies!
For one, caches are not exactly located on customer premises, either, right? They tend to be located in places that have easy access to power and are well-connected with fibres, and so far transmission speeds seem to be mostly going up.
Also, well, yes, social networks tend to be geographically localised, so I would very much expect p2p application traffic to also be geographically localized!?
Widely consumed content that's distributed in a p2p fashion obviously is just as amenable to caching as widely consumed content that's distributed by a central service, if it's distributed through some kind of content-addressed network. If that's cheaper for the ISP, they could just put caching nodes into their data centers.
Finally, I completely don't get why you think my communication should "generate revenue". My telephone calls don't generate any revenue either, do they? I simply pay someone for moving my bits around, that should be sufficient motivation for them to take care of moving my bits around.
In terms of generate revenue - I mean provide a service that people are willing to pay for at a level that will fund a network that enables the use case and decentralization. Current services are tending to deep reach from the datacentre, because that's cheap. If all services that people are willing to pay for are suited to that model that's what everyone will get. To have a different infrastructure model you need a service that people will pay for that is not well served by deepreach from the datacentre.
It's not the moving of the bits that is at issue, it's the how the bits are moved, where and who by.
Hu? Caches for geographical distribution are actually a form of decentralization! The problem with the existing ones is that they are mostly under centralized control, but there is no technical reason why that has to be, and an ISP's caching web proxy (which weren't that uncommon back in the day) is a simple example of caching infrastructure under decentralized control that could help an ISP reducing the load on their upstream connection for often-requested content. You don't need youtube to copy a video from your machine to the cache at some viewer's ISP, that's just the way it is commonly done right now because in that way youtube can make money - or, if you want to decentralize further, you could copy to a cache on the machine of some customer of said ISP in some geographic region: The more requests there are for some content, the more likely it is that there is a copy in your neighbourhood that doesn't need to be transferred from the original source.
So why don't they do this? Because of the difference between "shouldn't" and "wouldn't" at the end of the last paragraph. What if code to support ads - or other invasions of privacy - were embedded into every other thing they might open source? Then the sheer difficulty of refactoring to "sanitize" everything else would probably create a sufficient barrier to opening it up, and revealing how all of that ad infrastructure really works might hurt their business in other ways.
When Google continues to run as the new AOL (closed source, walled garden) I don't think it's part of a deliberate philosophy. Nor is it an accident. It's because their continued uber-prosperity, if not their actual survival, depends on it.
There is an issue of incentives, but I don't think it's as strong as you think. I think it's just that running services makes them money, while releasing open-source software doesn't, so they devote lots of effort to running services, and comparatively little to releasing open-source software.
It would be very challenging for them to open-source "as much software as they consume." That would be a many-billions-of-dollars effort. But it wouldn't be necessary — the great thing about software is that you can copy it, so even if you only release a tiny fraction of the amount of software as you "consume", everyone still benefits.
These are by no means crimes, but they're more evil than the things Google would have done in 2008 or 2009, and they're certainly not moving the internet in the direction I want to see it move in.
What do you mean by this? The documentation lists support for Chrome, IE, Firefox, and Safari.
"This setting applies to all Hangouts notifications from Gmail, Google+ and the Chrome extension on the same desktop computer."
Gmail and Google+ are both supported in all major browsers.
"I can understand asking why Hangouts doesn't work in Firefox. In short, we wanted to transition to WebRTC sooner rather than later, and at the moment there are things holding us back on both our side (e.g. upgrading our ICE implementation) and the Firefox side (e.g. supporting multiple video streams).
"But overall, surely you're not arguing that transitioning a major Google application from a proprietary plugin to an open web standard somehow demonstrates that Chrome doesn't value web standards."
1. Go to http://www.google.com/hangouts/
2. Click "get hangouts"
3. Click "computers"
Result is "You'll need to download Chrome before installing the Hangouts Chrome extension. Do you want to download Chrome now?"
edit: I think i remember being told on twitter that this was a confusing UI that would be changed. But that was several months ago.
If, however, you just start a hangout inside of gmail, it works fine in Chrome, Firefox, Safari, and IE (just hung out with myself on two computers in multiple browsers to test that out) and there was never a time that was broken, contrary to the GP post.
Perhaps this is just a confusing UI, but if so, it would be very easy to fix. If that's the case, I'm puzzled why it hasn't been fixed.
My only claim is that if you open up a chat window in gmail and hit the video button it works in other browsers and that using hangouts that way was never broken.
It seems unlikely to me that the assumption is that people that pick "computer" over "smartphone" distinctly want a native app as opposed to just running hangouts in the easiest way possible. All they did was click on "get hangouts".
There is no such ban. I've been using Hangouts with FireFox and IE for months. If you attempt to access a Hangouts url with FireFox, for example, it prompts you to install a FireFox plugin.
No, back in the nineties, you could not do any of the things he talks about. Not unless you were a high-status employee of a handful of major corporations or universities. Most people couldn't get online at all, and those who could were lucky to have client-only access to e-mail and the web.
Nowadays, anyone with a credit card and an Amazon account can set up an always-online server running pretty much any software they choose. The Internet is far more decentralized, by the criteria he invokes, then it was back then.
As I explained in the article, I did the things I talked about (running online services, including email and web pages, accessible from the entire internet) with a US$20/month dialup internet account on an ISP run by a group of MUDders who ran the ISP as a way to play MUDs, starting in 1997. I installed my first web server (from EIT's Webmaster's Starter Kit) temporarily on an IRIX workstation in a university computer lab, in 1994. I was an undergraduate student at UNM, a state university in the second-poorest state in the US, although I admit UNM was unusually progressive. The year before, I was an unpaid student system administration intern, with a user account on all the Suns at the math department, assigned tasks like "please get tvtwm to compile on SunOS 4.1.4; Prof X wants to use it".
I agree that it's pretty awesome that anyone who wants to pay Amazon or DigitalOcean US$5 a month (and can get access to a credit card they'll accept) can run any internet-facing server software they want. Unless they're WikiLeaks, say. Or infringing on an invalid Amazon software patent. Or just want to not have random employees have hardware access to their machine for reasons of security and privacy.
So I don't think the internet is far more decentralized. It's bigger, which is pretty great, and it's a lot cheaper, which is even better, but it's also more centralized.
It's also an advertising company, which means it brainwashes and deceives people in to buying garbage.
Both activities are unethical, and I wouldn't want anything to do with ether.
One of these things is not like the others. Three of these people have made significant contributions, in code. One of them has talked a lot and claimed the work of others as their own.