[Wikitech-l] ARM servers
Nicolas Charbonnier's Latest ARM Server solutions booths tour may be of some interest for those of you interested in low power server hardware: http://armdevices.net/2013/12/30/latest-arm-server-solutions-booths-tour/ Mitac isn't represented there, but he did an interview of them a year and a half ago: http://armdevices.net/2012/06/07/mitac-gfx-arm-server/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ARM servers
Hi! ARM servers is definitely worth to look at, but please be aware that technology is not mainstream and sad things may happens: http://calxeda.com (one of exhibitors of ARM TechCon). OS support if not mature yet, especially for ARMv8 (64 bit). Eugene. On Sun, Jan 12, 2014 at 1:05 AM, James Salsman jsals...@gmail.com wrote: Nicolas Charbonnier's Latest ARM Server solutions booths tour may be of some interest for those of you interested in low power server hardware: http://armdevices.net/2013/12/30/latest-arm-server-solutions-booths-tour/ Mitac isn't represented there, but he did an interview of them a year and a half ago: http://armdevices.net/2012/06/07/mitac-gfx-arm-server/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Jake requests enabling access and edit access to Wikipedia via TOR
On Tue, Dec 31, 2013 at 1:08 AM, Martijn Hoekstra martijnhoeks...@gmail.com wrote: Does Jake have any mechanism in mind to prevent abuse? Is there any possible mechanism available to prevent abuse? Preventing abuse is the wrong goal. There is plenty of abuse even with all the privacy smashing new editor deterring convolutions that we can think up. Abuse is part of the cost of doing business of operating a publicly editable Wiki, it's a cost which is normally well worth its benefits. The goal needs to merely be to limit the abuse enough so as not to upset the abuse vs benefit equation. Today, people abuse, they get blocked, they go to another library/coffee shop/find another proxy/wash rinse repeat. We can't do any better than that model, and it turns out that it's okay. If a solution for tor users results in a cost cost (time, money, whatever unit of payment is being expended) for repeated abuse comparable to the other ways abusive people access the site then it should not be a major source of trouble which outweighs the benefits. (Even if you do not value freedom of expression and association for people in less free parts of the world at all). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Jake requests enabling access and edit access to Wikipedia via TOR
This question is analogous to the question of open proxies. The answer has universally been that the costs (abuse) are just too high. However, we might consider doing what the freenode IRC network does. Freenode requires SASL authentication to connect on Tor, which basically means only users with registered accounts can use it. The main reason for hardblocking and not allowing registered accounts on-wiki via Tor is that CheckUsers need useful IP data. But it might be feasible if we just force all account creation to happen on real IPs, although that still hides some data from CheckUsers. On Sun, Jan 12, 2014 at 5:29 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Dec 31, 2013 at 1:08 AM, Martijn Hoekstra martijnhoeks...@gmail.com wrote: Does Jake have any mechanism in mind to prevent abuse? Is there any possible mechanism available to prevent abuse? Preventing abuse is the wrong goal. There is plenty of abuse even with all the privacy smashing new editor deterring convolutions that we can think up. Abuse is part of the cost of doing business of operating a publicly editable Wiki, it's a cost which is normally well worth its benefits. The goal needs to merely be to limit the abuse enough so as not to upset the abuse vs benefit equation. Today, people abuse, they get blocked, they go to another library/coffee shop/find another proxy/wash rinse repeat. We can't do any better than that model, and it turns out that it's okay. If a solution for tor users results in a cost cost (time, money, whatever unit of payment is being expended) for repeated abuse comparable to the other ways abusive people access the site then it should not be a major source of trouble which outweighs the benefits. (Even if you do not value freedom of expression and association for people in less free parts of the world at all). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla Weekly Report
MediaWiki Bugzilla Report for January 06, 2014 - January 13, 2014
Status changes this week
Reports changed/set to UNCONFIRMED: 6
Reports changed/set to NEW: 21
Reports changed/set to ASSIGNED : 22
Reports changed/set to REOPENED : 15
Reports changed/set to PATCH_TO_RE: 91
Reports changed/set to RESOLVED : 240
Reports changed/set to VERIFIED : 23
Total reports still open : 13621
Total bugs still open : 7962
Total non-lowest prio. bugs still open: 7749
Total enhancements still open : 5659
Reports created this week: 282
Resolutions for the week:
Reports marked FIXED : 172
Reports marked DUPLICATE : 22
Reports marked INVALID : 14
Reports marked WORKSFORME: 18
Reports marked WONTFIX : 11
Specific Product/Component Resolutions User Metrics
Created reports per component
MediaWiki extensions Flow 26
VisualEditor General 11
VisualEditor Editing Tools 10
MediaWiki General/Unknown 9
MediaWiki extensions MobileFrontend9
Created reports per product
MediaWiki extensions 111
Wikimedia 51
MediaWiki 43
VisualEditor 25
Wikimedia Labs12
Top 5 bug report closers
jrobson [AT] wikimedia.org21
aklapper [AT] wikimedia.org 19
mpinchuk [AT] wikimedia.org 11
matma.rex [AT] gmail.com 10
lydia.pintscher [AT] wikimedia9
Most urgent open issues
Product | Component | BugID | Priority | LastChange | Assignee
| Summary
--
Analytics | Tech communit | 57038 | Highest | 2013-12-23 |
acs[AT]bitergia.com | Metrics about contributors with +2 pe
MediaWiki | JavaScript| 52659 | Highest | 2013-12-16 |
wikibugs-l[AT]lists. | [Regression]: mediawiki.notification:
MediaWiki ext | CentralAuth | 54195 | Highest | 2013-12-30 |
csteipp[AT]wikimedia | CentralAuth not caching Special:Centr
MediaWiki ext | Diff | 58274 | Highest | 2013-12-10 |
wikibugs-l[AT]lists. | Implement an order-aware MapDiffer
MediaWiki ext | Echo | 53569 | Highest | 2013-12-18 |
wikibugs-l[AT]lists. | [Regression] Echo: Sending 2 e-mails
MediaWiki ext | Flow | 58016 | Highest | 2013-12-31 |
wikibugs-l[AT]lists. | Flow: Suppression redacts the wrong u
MediaWiki ext | WikidataRepo | 52385 | Highest | 2013-12-04 |
wikidata-bugs[AT]lis | Query by one property and one value (
MediaWiki ext | WikidataRepo | 58166 | Highest | 2013-12-09 |
wikidata-bugs[AT]lis | label/description uniqueness constrai
MediaWiki ext | WikidataRepo | 57918 | Highest | 2013-12-10 |
wikidata-bugs[AT]lis | show diffs for sorting changes
MediaWiki ext | WikidataRepo | 58394 | Highest | 2014-01-09 |
wikidata-bugs[AT]lis | specified index out of bounds issue
MediaWiki ext | WikidataRepo | 58850 | Highest | 2014-01-11 |
wikidata-bugs[AT]lis | wbmergeitems isn't merging claims pro
VisualEditor | Editing Tools | 50768 | Highest | 2013-12-16 |
rmoen[AT]wikimedia.o | VisualEditor: Better reference UI for
VisualEditor | General | 53093 | Highest | 2014-01-05 |
jforrester[AT]wikime | VisualEditor: Error: Unknown error
VisualEditor | MediaWiki int | 48429 | Highest | 2014-01-08 |
krinklemail[AT]gmail | VisualEditor: Support editing of sect
Wikimedia | Apache config | 31369 | Highest | 2013-12-10 |
tstarling[AT]wikimed | Non-canonical HTTPS URLs quietly redi
Wikimedia | Continuous in | 59935 | Highest | 2014-01-12 |
hashar[AT]free.fr| Jenkins: Zuul is consistently losing
Wikimedia | Git/Gerrit| 49846 | Highest | 2014-01-08 |
innocentkiller[AT]gm | mediawiki/extensions.git does not upd
Wikimedia Lab | Infrastructur | 48501 | Highest | 2013-12-20 |
greg[AT]wikimedia.or | beta: Get SSL certificates for *.{pro
Re: [Wikitech-l] Jake requests enabling access and edit access to Wikipedia via TOR
On Sun, Jan 12, 2014 at 6:36 PM, Jasper Deng jas...@jasperswebsite.com wrote: This question is analogous to the question of open proxies. The answer has universally been that the costs (abuse) are just too high. No, it's not analogous to just permitting open proxies as no one in this thread is suggesting just flipping it on. I proposed issuing blind exemption tokens up-thread as an example mechanism which would preserve the rate limiting of abusive use without removing privacy. However, we might consider doing what the freenode IRC network does. Freenode requires SASL authentication to connect on Tor, which basically means only users with registered accounts can use it. The main reason for hardblocking and not allowing registered accounts on-wiki via Tor is that CheckUsers need useful IP data. But it might be feasible if we just force all account creation to happen on real IPs, although that still hides some data from CheckUsers. What freenode does is not functionally useful for Tor users. In my first hand experience it manages to enable abusive activity while simultaneously eliminating Tor's usefulness at protecting its users. The only value it provides is providing a pretext of tor support without actually doing something good... and we already have the you can get an IPblock-exempt (except you can't really, and if you do it'll get randomly revoked. if all we want is a pretext. :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Jake requests enabling access and edit access to Wikipedia via TOR
On Mon, 13 Jan 2014, at 15:29, Gregory Maxwell wrote: On Sun, Jan 12, 2014 at 6:36 PM, Jasper Deng jas...@jasperswebsite.com wrote: This question is analogous to the question of open proxies. The answer has universally been that the costs (abuse) are just too high. No, it's not analogous to just permitting open proxies as no one in this thread is suggesting just flipping it on. I proposed issuing blind exemption tokens up-thread as an example mechanism which would preserve the rate limiting of abusive use without removing privacy. However, we might consider doing what the freenode IRC network does. Freenode requires SASL authentication to connect on Tor, which basically means only users with registered accounts can use it. The main reason for hardblocking and not allowing registered accounts on-wiki via Tor is that CheckUsers need useful IP data. But it might be feasible if we just force all account creation to happen on real IPs, although that still hides some data from CheckUsers. What freenode does is not functionally useful for Tor users. In my first hand experience it manages to enable abusive activity while simultaneously eliminating Tor's usefulness at protecting its users. The only value it provides is providing a pretext of tor support without actually doing something good... and we already have the you can get an IPblock-exempt (except you can't really, and if you do it'll get randomly revoked. if all we want is a pretext. :) The register at real IP, then only use TOR through an account flow implies trust in some entity (such as freenode irc network opers or Wikipedia CheckUsers). I currently believe that requiring such trust doesn't eliminate TOR's usefullness at protecting its users. Gryllida ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Want to Contribute
Hello, I am currently a 3rd year student and i want to contribute to Wikimedia. Please guide me how to get started asap. Thanks and Regards Vaibhav Gupta +919963855636 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikitech-l Digest, Vol 126, Issue 18
hi there, I am very interested in Wikimedia technologies and I want to ask one thing that how ca I contribute to it… I need to start as soon as possible but lacks some guidance but with all u guys I can achieve anything Thanks and Regards, Faizan Ayubi From: wikitech-l-requ...@lists.wikimedia.org Sent: Sunday, January 12, 2014 5:31 PM To: wikitech-l@lists.wikimedia.org Send Wikitech-l mailing list submissions to wikitech-l@lists.wikimedia.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.wikimedia.org/mailman/listinfo/wikitech-l or, via email, send a message with subject or body 'help' to wikitech-l-requ...@lists.wikimedia.org You can reach the person managing the list at wikitech-l-ow...@lists.wikimedia.org When replying, please edit your Subject line so it is more specific than Re: Contents of Wikitech-l digest... Today's Topics: 1. ARM servers (James Salsman) -- Message: 1 Date: Sun, 12 Jan 2014 17:05:03 +0800 From: James Salsman jsals...@gmail.com To: wikitech-l@lists.wikimedia.org Subject: [Wikitech-l] ARM servers Message-ID: CAD4=uZbTDNHS=avjgypae-akkepztrz9bovpm6+-svrfvxh...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Nicolas Charbonnier's Latest ARM Server solutions booths tour may be of some interest for those of you interested in low power server hardware: http://armdevices.net/2013/12/30/latest-arm-server-solutions-booths-tour/ Mitac isn't represented there, but he did an interview of them a year and a half ago: http://armdevices.net/2012/06/07/mitac-gfx-arm-server/ -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l End of Wikitech-l Digest, Vol 126, Issue 18 *** ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
