Proposal talk:Donated remote proxy server network

Impact?

Some proposals will have massive impact on end-users, including non-editors. Some will have minimal impact. What will be the impact of this proposal on our end-users? -- Philippe 00:41, 4 September 2009 (UTC)

having experienced how frustratingly slow it is to edit wikipedia in Buenos Aires compared to London I think that some sort of greater geographic spread of copies of Wikipedia would dramatically improve access speeds for our users and editors in areas of the world where we currently have slow access. I strongly suspect those will be the same places where the Wikis are currently struggling to take off. WereSpielChequers 21:48, 8 September 2009 (UTC)

Remote cache infrastructure doesn't speed up editing: All editing requests must go back to the master cluster in tampa (otherwise you couldn't resolve edit conflicts and such). As a logged-in user, at best a local cluster would have improved image load times. If you were using your own computer in Buenos Aires part of the slowness you saw may have, in fact, been caused by WMF's distribution: If you were still configured to use your london DNS servers your requests would have all gone from Buenos Aires to Amsterdam and then back to Tampa, with the response taking the reverse of that path. --Gmaxwell 20:42, 3 December 2009 (UTC)

Feasible?

Is this technically feasible? I don't think the proposal is based upon sound facts - please substantiate in particular the claims that server responses are significantly slower in some parts of the world, that this is hindering growth of some subset of wikis, and that this proposal would solve that issue. Mike.lifeguard | ^@meta 05:05, 9 September 2009 (UTC)

1) mike: the "main" wikipedia system requires factual evidence, notability etc. etc. and blatantly disregards "that which can be experienced" as "valid". however, this is not the "main" wikipedia system. to ask for "substantiation" in this instance, on the _strategy_ wiki, is counter-productive. please remember that the rest of the world does not have super fast internet connectivity. a substantial proportion of the population of New Zealand, a modern country that is a member of the british commonwealth, is still on 56kbaud (8k/sec!) dialup, and an even larger proportion is on 64k and 128k ISDN. in that regard, this proposal does not go far _enough_ and should be merged into Proposal:Distributed_Wikipedia. Lkcl 14:43, 30 September 2009 (UTC)

2) google wave shows that of course it's technically feasible. Lkcl 14:43, 30 September 2009 (UTC)

3) abiword's real-time edit collaboration plugin shows that of course it's technically feasible. Lkcl 14:43, 30 September 2009 (UTC)

4) the existence of git and other distributed source control systems, and the existence of bittorrent show that of course it's technically feasible. Lkcl 14:43, 30 September 2009 (UTC)

Proposal to merge with Proposal:Distributed_Wikipedia

the completion of the distributed wikipedia proposal would automatically result in donations of remote proxy server networks. see e.g. gnunetd and also bittorrent for ways in which the mere deployment (not the use of, by users) of a gnunetd or a bittorrent client results in the improvement of availability of services for everyone. Lkcl 16:38, 30 September 2009 (UTC)

This proposal is a self-contained indictment of the strategy process for technical proposals

I was pointed here by a professional contact with a passing comment along the lines of "man, those wikimedia people are kinda clueless". My forcefulness here is partially because this was somewhat embarrassing for me since people know I have had some technical involvement with Wikimedia in the past.

This proposal has existed for three months, full of claims of costless benefits, with nary a concern or objection expressed. Nor even a doubt that if it were really this good why hasn't it been done— after all, the foundation has a technical staff in charge of working on these sorts of things.

In ten minutes I was able to produce some dozen distinctive areas of concern, some expressing deep and difficult challenges any of which would be complete deal-breakers left unaddressed. The foundation has its own technical staff which could easily have provided these points, and many others— but they are busy accomplishing real work and don't have the time or patience to bother explaining to the inexperienced and uninformed that it isn't all as easy as it sounds.

Many of the other technical proposals here are similarly flawed but I, and apparently almost no one else is willing to go into battle with non-experts. We'd rather just ignore the foolish and unworkable proposals from the sidelines. As a rule of thumb any technical proposal which doesn't also express non-trivial costs which the proposal must be weighed against should probably be deleted.

Practically anyone can sit down and throw out a bunch of buzzwords and say "wouldn't be grand!": "Wikipedia XML-microformat social-mapping created by map-reduce cloud computing, FOR THE WIN!" Neat sounding ideas are a penny-per-dozen, the actual hard part in any technical proposal is in understanding the deep nuances and trade-offs. Without some of that analysis you can't even begin to decide if a technical proposal is worthwhile. A process which simply invites the uninformed to make fanciful sounding ideas simply robs time from the people with the knowledge and skills required to do this hard work, because they are left refuting naive proposals like this one.

A proposal for increased distribution which would be worth reading could be tendered but it wouldn't look anything like this one and it wouldn't likely come from someone who hasn't spent a considerable amount of time working with the technology.

Cheers. --Gmaxwell 20:39, 3 December 2009 (UTC)