Re: [Wikitech-l] Firesheep

2010-10-26 Thread MZMcBride
George Herbert wrote: > The current WMF situation is becoming "quaint" - pros use > secure.wikimedia.org, amateurs don't realize what they're exposing. > By professional standards, we're not keeping up with professional > industry expectations. It's not nuclear bomb secrets (cough) or > missile de

Re: [Wikitech-l] Firesheep

2010-10-26 Thread George Herbert
On Mon, Oct 25, 2010 at 11:59 PM, MZMcBride wrote: > George Herbert wrote: >> The current WMF situation is becoming "quaint" - pros use >> secure.wikimedia.org, amateurs don't realize what they're exposing. >> By professional standards, we're not keeping up with professional >> industry expectatio

Re: [Wikitech-l] Firesheep

2010-10-26 Thread Nikola Smolenski
On 10/26/2010 08:59 AM, MZMcBride wrote: > As Aryeh notes, even those who act in an editing role (rather than in simply > a reader role) don't generally have valuable accounts. The "pros" you're > talking about are free to use secure.wikimedia.org (which is already set up > and has been for quite s

Re: [Wikitech-l] Firesheep

2010-10-26 Thread John Vandenberg
On Tue, Oct 26, 2010 at 6:24 PM, George Herbert wrote: >.. > But I would prefer to move towards a logged-in user by default goes to > secure connection model.  That would include making secure a > multi-system, fully redundantly supported part of the environment, or > alternately just making https

Re: [Wikitech-l] Firesheep

2010-10-26 Thread Daniel Kinzler
On 26.10.2010 09:36, Nikola Smolenski wrote: > On 10/26/2010 08:59 AM, MZMcBride wrote: >> As Aryeh notes, even those who act in an editing role (rather than in simply >> a reader role) don't generally have valuable accounts. The "pros" you're >> talking about are free to use secure.wikimedia.org (

Re: [Wikitech-l] Firesheep

2010-10-26 Thread Conrad Irwin
There is no real massive load caused by https at runtime. There is however a significant chink of developer and sysadmin time needed to implement this and make it work. For now, at least, the only optimisations that should be considered are those that make it easier all round. Conrad On 26 Oct

Re: [Wikitech-l] InlineEditor new version (previously Sentence-Level Editing)

2010-10-26 Thread Alex Brollo
2010/10/25 Jan Paul Posma > Hi all, > > As presented last Saturday at the Hack-A-Ton, I've committed a new version > of the InlineEditor extension. [1] This is an implementation of the > sentence-level editing demo posted a few months ago. > > Very interesting! Obviously I'll not see your work ti

Re: [Wikitech-l] Parallel computing project

2010-10-26 Thread Platonides
Robert Rohde wrote: > Many of the things done for the statistical analysis of database dumps > should be suitable for parallelization (e.g. break the dump into > chunks, process the chunks in parallel and sum the results). You > could talk to Erik Zachte. I don't know if his code has already been

Re: [Wikitech-l] Parallel computing project

2010-10-26 Thread Jyothis Edathoot
Develop a new bot framework (may be interwiki processing to start with) for high performance GPU cluster (nvidia or AMD) similar to what boinc based projects does. nvdia is more popular while AMD has more cores for the same price :) Regards, Jyothis. http://www.Jyothis.net http://ml.wikipedi

Re: [Wikitech-l] Parallel computing project

2010-10-26 Thread Ariel T. Glenn
Στις 26-10-2010, ημέρα Τρι, και ώρα 16:25 +0200, ο/η Platonides έγραψε: > Robert Rohde wrote: > > Many of the things done for the statistical analysis of database dumps > > should be suitable for parallelization (e.g. break the dump into > > chunks, process the chunks in parallel and sum the result

Re: [Wikitech-l] Firesheep

2010-10-26 Thread Aryeh Gregor
On Tue, Oct 26, 2010 at 2:23 AM, Ashar Voultoiz wrote: > HTTPS means full encryption, that is either : >   - a ton of CPU cycles : those are wasted cycles for something else. >   - SSL ASIC : costly, specially given our gets/ bandwidth levels HTTPS uses very few CPU cycles by today's standards.

[Wikitech-l] New installer is here

2010-10-26 Thread Chad
Good afternoon, In r75437, r75438[0][1] I moved the old installer to old-index.php and moved the new to index.php. At this stage in the process, I don't see us backing this out before we branch 1.17. I really want people to test it out and report any major breakages [2]. This has been a long deve

Re: [Wikitech-l] New installer is here

2010-10-26 Thread Erik Moeller
2010/10/26 Chad : > Good afternoon, > > In r75437, r75438[0][1] I moved the old installer to old-index.php > and moved the new to index.php. At this stage in the process, > I don't see us backing this out before we branch 1.17. I really > want people to test it out and report any major breakages [2

Re: [Wikitech-l] New installer is here

2010-10-26 Thread Erik Moeller
2010/10/26 Erik Moeller : > A few quick notes: And, sorry for duplicating stuff from the known issues list. -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing

Re: [Wikitech-l] New installer is here

2010-10-26 Thread Brandon Harris
I am on ALL of these things, actually. I have fixes for most of them pending. On 10/26/10 10:41 AM, Erik Moeller wrote: > 2010/10/26 Chad: >> Good afternoon, >> >> In r75437, r75438[0][1] I moved the old installer to old-index.php >> and moved the new to index.php. At this stage in the

Re: [Wikitech-l] New installer is here

2010-10-26 Thread Erik Moeller
2010/10/26 Brandon Harris : > >        I am on ALL of these things, actually.  I have fixes for most of them > pending. Awesome :-) -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate _

Re: [Wikitech-l] Parallel computing project

2010-10-26 Thread Tisza Gergő
Aryeh Gregor gmail.com> writes: > To clarify, the subject needs to 1) be reasonably doable in a short > timeframe, 2) not build on top of something that's already too > optimized. It should probably either be a new project; or an effort > to parallelize something that already exists, isn't paral

Re: [Wikitech-l] Parallel computing project

2010-10-26 Thread Tim Starling
On 24/10/10 17:42, Aryeh Gregor wrote: > This term I'm taking a course in high-performance computing > , and I have > to pick a topic for a final project. According to the assignment >

Re: [Wikitech-l] New installer is here

2010-10-26 Thread Brion Vibber
On Tue, Oct 26, 2010 at 10:00 AM, Chad wrote: > This has been a long development process for almost 2 years > now, and I'd like to thank Max, Mark H., Jure, Jeroen, Roan > and Siebrand for their invaluable help in working on this. And > especially thanks to Tim for starting the project and provid

Re: [Wikitech-l] Parallel computing project

2010-10-26 Thread Robert Rohde
On Tue, Oct 26, 2010 at 8:25 AM, Ariel T. Glenn wrote: > Στις 26-10-2010, ημέρα Τρι, και ώρα 16:25 +0200, ο/η Platonides έγραψε: >> Robert Rohde wrote: >> > Many of the things done for the statistical analysis of database dumps >> > should be suitable for parallelization (e.g. break the dump into

Re: [Wikitech-l] Parallel computing project

2010-10-26 Thread Ángel González
Ariel T. Glenn wrote: > If one were clever (and I have some code that would enable one to be > clever), one could seek to some point in the (bzip2-compressed) file and > uncompress from there before processing. Running a bunch of jobs each > decompressing only their small piece then becomes feasib

Re: [Wikitech-l] Parallel computing project

2010-10-26 Thread Ariel T. Glenn
Στις 27-10-2010, ημέρα Τετ, και ώρα 00:05 +0200, ο/η Ángel González έγραψε: > Ariel T. Glenn wrote: > > If one were clever (and I have some code that would enable one to be > > clever), one could seek to some point in the (bzip2-compressed) file and > > uncompress from there before processing. Run

[Wikitech-l] Parralel computing project

2010-10-26 Thread Erik Zachte
Robert Rohde: Getting back to Wikimedia, it appears correct that the Wikistats code is designed to run from the compressed files (source linked from [1]). As you suggest, one could use the properties of .bz2 format to parallelize that. I would also observe that parsers tend to be relatively s

Re: [Wikitech-l] Commons ZIP file upload for admins

2010-10-26 Thread Maciej Jaros
@2010-10-26 03:45, Erik Moeller: > 2010/10/25 Brion Vibber: >> In all cases we have the worry that if we allow uploading those funky >> formats, we'll either a) end up with malicious files or b) end up with lazy >> people using and uploading non-free editing formats when we'd prefer them to >> use

[Wikitech-l] RT

2010-10-26 Thread a b
After the recent dicussions open open-ness and clarity with requests by serveral people what is contained within the RT after several people have asked and given answers like "it's staff stuff". So what is stored in it that can't be within either the staff or internal wiki where it must be private

Re: [Wikitech-l] Commons ZIP file upload for admins

2010-10-26 Thread John Vandenberg
On Tue, Oct 26, 2010 at 6:50 AM, Max Semenik wrote: > >> > > Instead of amassing social constructs around technical deficiency, I > propose to fix bug 24230 [1] by implementing proper checking for JAR > format. Also, we need to check all contents with antivirus and > disallow certain types of file

Re: [Wikitech-l] New installer is here

2010-10-26 Thread Andrew Garrett
On Wed, Oct 27, 2010 at 4:00 AM, Chad wrote: > In r75437, r75438[0][1] I moved the old installer to old-index.php > and moved the new to index.php. At this stage in the process, > I don't see us backing this out before we branch 1.17. I really > want people to test it out and report any major brea

Re: [Wikitech-l] RT

2010-10-26 Thread Ryan Lane
On Tue, Oct 26, 2010 at 4:39 PM, a b wrote: > After the recent dicussions open open-ness and clarity with requests by > serveral people what is contained within the RT after several people have > asked and given answers like "it's staff stuff". > > So what is stored in it that can't be within eith