from_name: Arno M

subject: [WikiEN-l] Irismeister

body:
Isn't this guy now at the arbitration committee stage?
It sounds like this matter needs a moveon.

(BTW , my first entry!)
--

--------- Original Message ---------

DATE: Tue, 24 Feb 2004 08:39:09
From: "KNOTT, T" <tknott at qcl.org.uk>
To: "English Wikipedia" <wikien-l at Wikipedia.org>
Cc:

>Can I ask for people to help me out a bit here. Irismeister is following me around trying to provoke me. My tactic of doing my best to ignore him seems to be winding him up as he made a couple of absurd edits yesterday - he removed "if swallowed ....... seek medical help" from ammonium chloride on the ground that seeking medical help from unqualified persons wastes time and is therefore dangerous. This _may_ be because english is not his first language and he doesn't realize the phrase means - go to a doctor or ring the emergency services, but I think it's just that he's baiting me.
>
>Another example is on the reflexology page where he deleted a quote that I put in calling it obscene. This is the most ridiculous thing I ever heard so I reverted.
>
>My problem is, I am now at the stage where I simply revert all the deletions he makes of my work without even considering his arguments. It may well be that I make a bad edit, irismeister reverts it and I revert it back again simply because it was him. I am concerned that other editors may be reluctant to argue with me for fear of agree with him, or even for fear of getting involved in the war. So I'm asking for you lot's help. If you see me revert irismeister and you think that even though he is a jerk, his edit had some merit please say so on the talk page. I can't bring myself to argue my case with him anymore, but I don't want the quality of wikipedia to suffer as a result.
>
>Cheers.
>
>Theresa
>
>
>_______________________________________________
>WikiEN-l mailing list
>WikiEN-l at Wikipedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikien-l
>

____________________________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10


list: wikien-l

source: pipermail-mbox

subject: [WikiEN-l] Plautus

body:
Speaking of which - this guy now has 21 signatures (myself included) who want him banned. He is continuing to make a joke out of the Sep 11 page and antagonising other users. When will something be done?

--

--------- Original Message ---------
DATE: Tue, 24 Feb 2004 16:36:01
From: "Poor, Edmund W" <Edmund.W.Poor at abc.com>
To: "English Wikipedia" <wikien-l at Wikipedia.org>
Cc:

See:
http://en.wikipedia.org/wiki/User_talk:Ed_Poor#Plautus_Satire_Chooses_Wikirolemodel
I hope this is for real :-)
Ed Poor

____________________________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040225/ea065b86/attachment.htm


from_name: Ray Saintonge

subject: [WikiEN-l] "Go" back to WikiBooks vs. Wikipedia discussion

body:
Poor, Edmund W wrote:

>Nobody mentioned yet that there are 3 different size go boards in common
>use:
>
> 9 x 9
>13 x 13
>19 x 19
>
>As mentioned, of course, the boards are slightly off-square, to offset
>the effect of looking at the board from an angle.
>
I'm familiar with the idea, but I think that the reasing is incorrect.
 IIRC (since I can't easily find my reference) it had something to do
with the Zen dilike of anything that is perfectly symmetrical.

>And most importantly
>the board is not conceived as being divided into squares but hashed with
>lines: markers are placed at the intersections of these lines. Territory
>consists not of "area" but of the count of /points/ cordoned off by the
>markers of one color.
>
>...not sure how this relates to recipes.
>
>We do have an article on go, which contains tips on tactics and
>strategy. I sure hope the whole thing isn't deleted and/or moved to
>WikiBooks!
>
See http://en.wikipedia.org/wiki/Talk%3APoker_strategy

Ec


list: wikitech-l

from_name: Brion Vibber

subject: [Wikitech-l] Unbelieveable 1.1.0

body:
On Feb 24, 2004, at 21:53, ciaran wrote:
> I really wish I hadn't "upgraded" to this recommended version. But I
> won't go into all the issues here.
>
> One question: The status of links (broken, existing) NO LONGER UPDATE
> on any Wiki posts. Does anyone know why this is? I don't ever plan on
> implementing memcache (the lack of real documentation as to how I can
> do it being the primary reason)... is this an issue for future
> wikipedia releases? Is memcache (or lack thereof) ruining the Wiki's
> ability to update broken/not broken links?

Probably nothing to do with memcache, as memcache is not used for links
in any way at present. Note that problems with link updates can be
caused by errors that occur at save time, which may be hidden by the
subsequent HTTP redirect to view the page. Try disabling the redirect
for debugging purposes. (Grep for 'Location:' and comment out the
header() call including it to disable automatic redirects.)

Are you using MySQL 3.x? If so, did you put $wgEnablePersistentLC   =
false; into LocalSettings.php?

If not, could you check that the linkscc table is present?

Can you confirm that links are not being updated, rather than cached
pages not being updated?

Can you check your Apache error log for PHP error messages? Is PHP
configured to log error messages? What version of PHP are you running?

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040225/4a0db692/attachment.pgp>


from_name: Fred Bauder

subject: [WikiEN-l] Irismeister

body:
Very clever, so it is true? And truth a defense?

Fred

> From: "Poor, Edmund W" <Edmund.W.Poor at abc.com>
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: Wed, 25 Feb 2004 14:31:02 -0500
> To: "English Wikipedia" <wikien-l at Wikipedia.org>
> Subject: RE: [WikiEN-l] Irismeister
>
> I will be happy to present evidence that Irismeister has been called a
> quack and a nutcase.
>
> Irismeister is a quack and a nutcase. There!
>
> (Ah, that felt good to say!)
>
> /ducks and covers/
>
> Ed
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: Nick Reinking

subject: [Wikitech-l] Two projects I'm exploring

body:
On Wed, Feb 25, 2004 at 11:19:45AM -0700, Kelly Anderson wrote:
>
> >Well, an order of magnitude means we can do the same amount of work with
> >half the machines we have now, or twice as much with the same.  That's a
> >pretty big deal.  That said, rewriting the entire codebase in C/C++ will
> >take a huge amount of developer time.  If there are any time-sensitive
> >spots in the code, it might be worth recoding those in C/C++ - but I
> >don't know about the entire codebase.  I really don't think that's a
> >"win", as far as developer time, or future maintainability.
>
> Is it possible to write part of a single page PHP program in C++? Or do you
> have to make the entire page into a CGI?
>
> I've got a lot of C++ experience, but very little PHP. I suspect that there
> are a lot more C++ programmers than PHP programmers out there, and we like
> to help. :-)

No, what you would do is extended PHP itself C/C++.  Essentially, you'd
be adding a new Wikipedia module into PHP, and then calling those
functions.

--
Nick Reinking -- eschewing obfuscation since 1981 -- Minneapolis, MN


from_name: Anthere

subject:
[WikiEN-l] Re: HOWTOs/Recipes/Instructions and other
	imperativecontent

body:
Daniel Mayer a ?crit:
> Cimon Avaro wrote:
>
>>(pardon my french) The original french encyclopaedists
>>made a point of detailing as many crafts and industries
>>as possible, down to the most minute detail, with graphic
>>illustrations capable of practical implementation. This is
>>what made them notable in their own time as spreading
>>the industrial revolution.
>
>
> And the ones in the English tradition have tended to shy away from
> instructional material and language.
>
> Again, different cultures will have different ideas about how to best organize
> information. The instructional/informative and textbook/encyclopedia
> distinction seems to me to be rather prevalent in the English language
> tradition.
>
> But different cultures may have different ways of doing things. However, much
> of the current situation can be fixed by converting the recipes into
> encyclopedia articles (informative voice) and moving the rest to Wikibooks.
>
> Both projects would benefit from this.
>
> I do not favor deletion.
>
> -- mav

Usually...the next step when I try to speak again, is to tell me that I
can do whatever I want on the french wikipedia, but that this is the
english wikipedia.

I should list the most frequently used arguments to make people shut
up...hum...idea  :-) !


list: wikipedia-l

from_name: Kurt Jansson

subject: [Wikipedia-l] great news!

body:
Yesterday there was an article about Wikipedia in Spiegel-Online, the
biggest German online news-magazine (30 million visits/month), and I'm
sure we got more new German Wikipedians yesterday than ever before.

Through this article the TV took notice of us, and so there will be a
feature (right word?) about us in the "Tagesthemen" at 22:30 (ARD). I
think this is really great news.

Thanks to all the people who keep the site running, the increase of
visitors after the Spiegel-Online article went online was quite
impressive, but the servers seem to handle it without problems.

Our reader love us, the media loves us, at the moment I'm quite happy
and I know I'm not alone with this feeling. This is a great project, and
everybody can be proud to be part of it.

Kurt

--
http://leihnetzwerk.de -- Vielleicht hat Dein Nachbar das Buch, das Du
                           schon immer lesen wolltest - leih es Dir aus!
http://wikipedia.de    -- Die freie Enzyklop?die
http://jansson.de      -- Icke


from_name: Jussi-Ville Heiskanen

subject: [WikiEN-l] HOWTOs/Recipes/Instructions and otherimperative	content

body:
On Wed, 2004-02-25 at 13:25, Charles Matthews wrote:

    Ray Saintonge wrong

    > Hmm!  I recently learned that 42 was the meaning of life and everything.
    >  That goes beyond go.

    Hey, that's POV too!  As a teaser, can I say that the tricky point here is
    that go boards are rectangular, rather than square (8% to compensate for
    foreshortening).

    Charles

At the risk of "blowing the gaff", and in the intrest of containg this
thread from becoming a spammed one, let me explicte!

A go board does not contain squares. The markers are placed at
intersections of lines.
A master will give handicap to a novice, by allowing the novice to place
four markers,
which in themselves define a rectangular space, which the master will
envision as a
square, although it is not a square geometrically.

Cimon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040225/9447e306/attachment.htm


subject: [Wikitech-l] No arrows .png files in the phase3 head revision

body:
On Feb 25, 2004, at 13:31, Nick Pisarro wrote:
> The arrow files, Arr_r.png, Arr_d.png, and Arr_.png used in the new
> 'recent changes' feature, do not seem to be in phase3/images.

IIRC the last time this was brought up, they weren't added immediately
because a) we're not sure where they came from and b) somebody offered
to make new ones.

Anybody want to make new, prettier ones of known provenance?

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040225/89721665/attachment.pgp>


from_name: Brian Corr

subject: [WikiEN-l] Plautus

body:
I know folks are busy with Irismeister right now, but Plautus satire seems
to be eating up a lot of people's time -- both on talk pages and on
whichever article he decides to target -- currently
http://en.wikipedia.org/wiki/Talk:Tornado and
http://en.wikipedia.org/wiki/Tornado

Could someone give an update on a timeline for action?

Thanks, Brian (Bcorr)

At 12:40:27 2/25/04 +0600, you wrote:
>Date: Wed, 25 Feb 2004 12:40:27 +0600
>From: "Arno M" <redgum46 at lycos.com>
>Subject: [WikiEN-l] Plautus
>
>Speaking of which - this guy now has 21 signatures (myself included) who
>want him banned. He is continuing to make a joke out of the Sep 11 page
>and antagonising other users. When will something be done?


from_name: Sean Barrett

body:
> As mentioned, of course, the boards are slightly off-square, to offset
> the effect of looking at the board from an angle. And most importantly
> the board is not conceived as being divided into squares but hashed with
> lines: markers are placed at the intersections of these lines. Territory
> consists not of "area" but of the count of /points/ cordoned off by the
> markers of one color.
>
> ...not sure how this relates to recipes.

Not recipes, but the fact that Go is an unacceptable topic for
Wikipedia: the very raison d'etre of the off-square-ness of the grid
is the player POV.  NPOV requires a square grid.

--
 Sean Barrett     | You non-conformists are all alike.
 sean at epoptic.com |


from_name: Poor, Edmund W

body:
Nobody mentioned yet that there are 3 different size go boards in common
use:

 9 x 9
13 x 13
19 x 19

As mentioned, of course, the boards are slightly off-square, to offset
the effect of looking at the board from an angle. And most importantly
the board is not conceived as being divided into squares but hashed with
lines: markers are placed at the intersections of these lines. Territory
consists not of "area" but of the count of /points/ cordoned off by the
markers of one color.

...not sure how this relates to recipes.

We do have an article on go, which contains tips on tactics and
strategy. I sure hope the whole thing isn't deleted and/or moved to
WikiBooks!

Ed Poor


subject: [WikiEN-l] Irismeister

body:
I will be happy to present evidence that Irismeister has been called a
quack and a nutcase.

Irismeister is a quack and a nutcase. There!

(Ah, that felt good to say!)

/ducks and covers/

Ed


from_name: KNOTT, T

subject: [WikiEN-l] HOWTOs/Recipes/Instructions and other imperativecontent

body:
I really don't think it matters if recipes and other how to's are on wikipedia or on wikibooks, as long as they are not deleted totally. Can we come to some agreement on what to do and just do it. I would like a policy in place so that they don't keep getting listed on VfD.

Theresa


from_name: Jimmy Wales

subject: [Wikitech-l] Request

body:
How quickly can we add a "Yahoo" searchbox to the "Full text search
has been disabled temporarily" page?

Yahoo has an 'advanced search' capability that is exactly like Google's
for restricting a search to a domain:

http://search.yahoo.com/search?x=op&va=Thomas+Jefferson&va_vt=any&vs=en.wikipedia.org

...for example.

This is a request from Yahoo that I'd like to rush to accomodate, as
they are showing lots of WikiLove toward the project of late.

--Jimbo


subject: [WikiEN-l] Plautus

body:
Ed Poor is helping Plautus to try to learn the norms of the community,
and has great hopes for the future.  Plautus has also written to me
expressing a desire for change.

I will also try to help.

In the meantime, show him love.  Love is the only hope for us all.
If that doesn't work, well, at least we tried.

--Jimbo

Brian Corr wrote:

> I know folks are busy with Irismeister right now, but Plautus satire seems
> to be eating up a lot of people's time -- both on talk pages and on
> whichever article he decides to target -- currently
> http://en.wikipedia.org/wiki/Talk:Tornado and
> http://en.wikipedia.org/wiki/Tornado
>
> Could someone give an update on a timeline for action?
>
> Thanks, Brian (Bcorr)
>
> At 12:40:27 2/25/04 +0600, you wrote:
> >Date: Wed, 25 Feb 2004 12:40:27 +0600
> >From: "Arno M" <redgum46 at lycos.com>
> >Subject: [WikiEN-l] Plautus
> >
> >Speaking of which - this guy now has 21 signatures (myself included) who
> >want him banned. He is continuing to make a joke out of the Sep 11 page
> >and antagonising other users. When will something be done?
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Stan Shebs

subject: [Wikitech-l] Request

body:
Jimmy Wales wrote:

>This is a request from Yahoo that I'd like to rush to accomodate, as
>they are showing lots of WikiLove toward the project of late.
>
I hadn't heard that Yahoo even knew WP existed - what form is all this
WikiLove taking? Hopefully not one of those "special" kinds of love... :-)

Stan


subject: [WikiEN-l] Paul Vogel and anon IDs

body:
I'm a little confused.  Why are people so adamant against having an
article "White Separatism"?  Rather than banging our head against the
wall fighting this guy, why not just make a better article?

The junk this guy is inserting is junk.  It looks like a quote from
someone, and if it is, then it's probably worth treating in a short
article on the subject.

There's nothing inherently wrong (that I know of) about having an
article on "White Separatism" as distinct from (but related to) "White
Supremacy".

Here's a book about it:
http://www.amazon.com/exec/obidos/tg/detail/-/0801865379/102-0949346-1338507?v=glance

My dictionary (American Heritage) has separate entries for "White
separatist" and "White supremacy".

The (in my opinion, disgusting) point of view expressed in the quote
is of encyclopedic interest because it *is* a point of view held by at
least some people who take action in the world, action that should
concern us all.

David Gerard wrote:

> See
>
> http://en.wikipedia.org/wiki/Wikipedia:Conflicts_between_users#Paul_Vogel/65.125.10.66/24.45.99.191/216.99.245.171
>
> He's coming in from three IPs and putting the same bit of spam into
> a set of articles and their talk pages (and those of anyone who
> reverts the spam).
>
> He intends to continue however possible:
>
> http://en.wikipedia.org/w/wiki.phtml?title=Talk:White_supremacy&diff=2458552&oldid=2458453
>
> "WE can revert until the cows come home as long as a NPOV is not being
> maintained regarding this strictly Marxist-PC POV propaganda article."
>
> At what point should an anon user be blocked for spam? Is there a
> measure of what's spamming on Wikipedia?
>
> (And I am following bcorr's example and trying to keep reverts to
> no more than three per article.)
>
>
> - d.
>
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [Wikitech-l] Re: Faster parsing (was: Two projects I'm exploring)

body:
On Feb 25, 2004, at 14:48, Timwi wrote:
> My guess is

I hereby forbid all discussion of optimization and slow spots until
somebody profiles actual running code and has data to show where the
slow spots are.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040225/57814153/attachment.pgp>


body:
Brion Vibber wrote:
> On Feb 25, 2004, at 14:48, Timwi wrote:
> >My guess is
>
> I hereby forbid all discussion of optimization and slow spots until
> somebody profiles actual running code and has data to show where the
> slow spots are.

Seconded.

In my opinion, performance is perfectly fine right now.  It could be
better, of course, I mean, anything could always be better, right?

And we're running with a suboptimal db server.  suda has a load
average of 3-4 fairly often, while geoffrin (when running) had a load
average under 1.0 m ost of the time.

When Geoffrin is healed and here (just over a week from now, I think),
then we'll have 2 db servers, and we can do some simple load balancing
on those.

And our current architecture is now very reasonably scalable, *after*
we come to some understanding of where bottlenecks might be.  If we
need more webservers, or more RAM in some squids, or more database
servers, we will find it fairly easy to just add them.

I'm personally still a lot more focussed on *reliability*.  We want to
work hard to make sure that wikipedia always answers every request.

I've already made my campaign against worrying about arcane
possibilities like datacenter failure and whatnot.  Those are good to
think about in the abstract, but we have other issues *right now*.

(Although nothing so serious as what we faced over the holidays, of
course.)

--Jimbo


subject: [Wikitech-l] Request

body:
Stan Shebs wrote:
> >This is a request from Yahoo that I'd like to rush to accomodate, as
> >they are showing lots of WikiLove toward the project of late.
> >
> I hadn't heard that Yahoo even knew WP existed - what form is all this
> WikiLove taking? Hopefully not one of those "special" kinds of love... :-)

They're interested in re-using some of our content in their movies and
entertainment areas, possibly more, and we've chatted a bit about how
they could do that.  They sounded favorable to the idea of donating
some money.  They love us.

And they're offering us a way to work directly with their new system
so that our content can be indexed more or less realtime, i.e. we will
give them an ability to grab an xml feed.

--Jimbo


subject: [Wikitech-l] Request

body:
On Feb 25, 2004, at 14:41, Jimmy Wales wrote:
> How quickly can we add a "Yahoo" searchbox to the "Full text search
> has been disabled temporarily" page?

Added on en. It's not pretty but it works.

The form can be added in at:
http://en.wikipedia.org/wiki/MediaWiki:Googlesearch
(or equivalent)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040225/3f5083bf/attachment.pgp>


subject: [Wikitech-l] Request

body:
On Feb 25, 2004, at 14:53, Ivan Krstic wrote:
> This should not be hard to do. On the other hand, for the search you
> listed below, Yahoo notably fails to produce a link to [[Thomas
> Jefferson]] in *any* of their results (not just the first 20 - the
> link is simply not there!), whereas it is the first result on Google.

Indeed, Yahoo seems to quite reliably _not_ turn up the page with the
exact title you're searching for.

Thomas Jefferson, atmospheric pressure, Abraham Lincoln,
military-industrial complex, Napoleonic wars... Ah, it did turn up
European Union. Well, one out of six ain't bad. Well, I know which
search I'm sticking with for my daily needs... :)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040225/1c06ad0b/attachment.pgp>


from_name: Charles Matthews

body:
> I really don't think it matters if recipes and other how to's are on
wikipedia or on wikibooks, as long as they are not deleted totally. Can we
come to some agreement on what to do and just do it. I would like a policy
in place so that they don't keep getting listed on VfD.
>
> Theresa

Well, I believed it was policy they all went to wikibooks; I thought and
think that that's a good, clear policy; and not one that hampers changing
the policy later if other thoughts prevail.

Charles


from_name: James Rosenzweig

subject: [WikiEN-l] Protected Wikipedia:Main Page

body:
Isomorphic caught someone vandalizing [[Wikipedia:Main
Page]].  Iso reverted, and I decided to protect that
page for essentially the same reasons that the Main
Page has traditionally been protected.  If you
disagree, I have noted the protected status at
[[Wikipedia talk:Main Page]] (and listed it as
semi-permanently protected at [[Wikipedia:Protected
page]]), and am happy to discuss things at W:MP's talk
page.  I assume I have done the right thing, but am
happy to hear other perspectives.

James Rosenzweig

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools


from_name: Till Westermayer

subject: [Wikipedia-l] Re: What would Richard Stallman say? (IP users)

body:
. . . . . . . . . . . . . . . . . . . . . . . . . . . till we *) . . .

>Till Westermayer <till at tillwe.de> writes:

>> Depends. In the US, you can, in Germany, you can't.

>I guess you meant the "urheberrecht" in Germany - it is
>conceptionally different from the US copyright.  The one who
>creates a work owns the "urheberrecht" and he or she can grant the
>right to make use of the work to somebody else.  That's it
>roughly.

Yeah. And if a person in Germany creates a work, s/he will own the
urheberrecht and the copyright. Even if s/he seels the copyright, s/he
will still own the urheberrecht. As far as I know, this situation
doesn't exist in the USA, and I think some of the confusion about this
topic is related to that non-universal distinction.

 __ .
 / / / /                            ... Till Westermayer - till we *)
. .
  . mailto:till at tillwe.de . www.westermayer.de/till/ . icq 320393072
  . Habsburgerstr. 82 . 79104 Freiburg . 0761 55697152 . 0160 96619179
  . . . . .


subject: [WikiEN-l] Re: recipes

body:
Peter Jaros wrote:

> On Feb 24, 2004, at 11:51 PM, Ray Saintonge wrote:
>
>> Peter Jaros wrote:
>>
>>> Giving a recipe for a particular chocolate cake would not serve to
>>> describe chocolate cake.  If one recipe was particularly famous,
>>> however, it might merit its own section (or possibly article; I'd
>>> like to try *that* cake) where the recipe *would* be descriptive.
>>> It's a subtle distinction, but an important one.  It comes through
>>> to readers, if only in terms of a sense of the style.
>>
>> That's very patronizing of you.
>
> Sorry, I worded that poorly.  What I meant that the distinction may
> not jump out at casual readers, but it sounds better nonetheless.  As
> analogy, using the wrong word in a sentence and making the sentence
> meaningless is obvious to even a casual reader, while using casual
> language in a formal setting is often "felt" while not directly
> noticed.  It can take a bit of working with a sentence to figure out
> what in it sounds too casual (or too formal, or awkward, etc.).

I do get a little hot over these deletion issues. :-)

The expression that I found most patronizing  was "it might merit its
own section".  I suspect that the subtleties between descriptive and
prescriptive or between imperatiuve and indicative might not be
meningful to the casual reader who wants to find out about a food and/or
how to make it.  The technical detailsof chocolate cakes are not
inherently controversial.  If different ways exist for making such a
cake, the results of which is better can be entirely subjective.

Using a wrong word that gives the sentence a different meaning, rather
than just making it meaningless can launch a discussion into a very
different direction.  I confess to being quick to notice this kind of
thing as I did with the earlier part of your previous post.
 "Proscriptive" and "prescriptive" have almost contradictory meanings,
but grammaticaly can fit equally well into the same context.  I couldn't
pass up the opportunity.

Ec


from_name: Nick Pisarro

subject: [Wikitech-l] Two projects I'm exploring

body:
Wikimedia developers <wikitech-l at Wikipedia.org> writes:
>But
>separating the two functions of the parser -- parsing Wiki markup,
>generating HTML -- would make the parser a lot easier to work with,
>and we could make enhancements more easily. Also, of course, the whole
>multiple output channel thing.

Yes, excellent idea!

In fact I am proposing doing just such an operation in our company for one
of our products. In that case, I need to blow apart an .html file much
like you would do for XML, change some .html tags, which may involve
pruning the tree, then walk the tree to generate a new .html file.

It didn't occur to me that it might be worthwhile for this application.
Parsing it to a tree first may not be that costly as you have probably
have to make two passes anyway. For example, you can't generate the Table
of  Contents in the front until you've process the whole file. There may
be some advantage to processing all the internal links at once. For the
second pass you'd really like to work with some intermediate form, rather
than working with the original or modified text string.

Nick Pisarro


body:
The arrow files, Arr_r.png, Arr_d.png, and Arr_.png used in the new
'recent changes' feature, do not seem to be in phase3/images.

Nick Pisarro

P.S. Is this the right place to post a notice like this?--Nick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Arr_d.png
Type: image/png
Size: 289 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040225/adb6e631/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Arr_.png
Type: image/png
Size: 918 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040225/adb6e631/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Arr_r.png
Type: image/png
Size: 282 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040225/adb6e631/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Arr_r.png
Type: image/png
Size: 282 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040225/adb6e631/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Arr_d.png
Type: image/png
Size: 289 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040225/adb6e631/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Arr_.png
Type: image/png
Size: 918 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040225/adb6e631/attachment-0005.png>


body:
LOL! You want to step outside and repeat that remark? You know, a boxing
ring is square, too!! ;-)

Ed

-----Original Message-----
From: Sean Barrett

Not recipes, but the fact that Go is an unacceptable topic for
Wikipedia: the very raison d'etre of the off-square-ness of the grid is
the player POV.  NPOV requires a square grid.


from_name: Neil Harris

subject: [Wikitech-l] Two projects I'm exploring

body:
Nick Reinking wrote:

>On Wed, Feb 25, 2004 at 11:07:30AM -0500, Ivan Krstic wrote:
>
>
>>Now that Magnus mentioned it on Meta, I'm more inclined to ask: is
>>writing Phase IV in C/C++ something that's being actively considered?
>>Sure, it's an effort, but we're looking at - minimally - an order of
>>magnitude improvement in performance. That does, however, raise the
>>question of whether it's worth it to reinvent the wheel (Phase III is
>>great software) for a problem that, in the foreseeable future, can be
>>solved cheaply by throwing more processor horserpower into the mix, and
>>by better caching.
>>
>>-IK
>>
>>
>
>Well, an order of magnitude means we can do the same amount of work with
>half the machines we have now, or twice as much with the same.  That's a
>pretty big deal.  That said, rewriting the entire codebase in C/C++ will
>take a huge amount of developer time.  If there are any time-sensitive
>spots in the code, it might be worth recoding those in C/C++ - but I
>don't know about the entire codebase.  I really don't think that's a
>"win", as far as developer time, or future maintainability.
>
>
>
I doubt whether you'd get an order of magnitude performance enhancement.
Nick is right.

The 90-10 law applies here: 90% (or more) of the time is spent in 10%
(or less) of the code. The problem is that often you don't know which
10%.  For example, there's not much point in making the system 10 times
faster at the CPU level if it's I/O-bound: it will just spend 90% of the
time waiting for I/O without running any faster. [[Amdahl's law]]
applies to software as well as hardware.

There's also not much point in rewriting the whole thing if you could
have got almost the same gain by just rewriting a few percent of the
code, and not made every part of the system far less maintainable by
rewriting it in a low-level language.

What makes sense is measuring hot-spots using diagnostic tools, looking
at algorithms to see if algorithmic complexity can be reduced, finding
places where parallelism can be increased, or faster hardware deployed,
or _very selective_ low-level acceleration code added.

More MRTG monitoring of stats from the various servers, and the public
availability of the low-level SMTP stats files, would be very useful
indeed in locating the hot-spots, allowing better decisions to be made
about how to spend resources of all or any of these kinds.

-- Neil


subject: [Wikitech-l] Faster parsing (was: Two projects I'm exploring)

body:
Poor, Edmund W wrote:

>Um, there is, I, (pause to remove foot from mouth)
>
>Reducing time from .99 to .97 doesn't sound very important. But I still
>think that efforts to reduce page delivery time are important. Any idea,
>no matter how far-fetched, should be considered.
>
>Naturally, the proof is in the pudding. So after we try a given
>optimization, we ought to measure the results and see if it really gets
>the pages to the users any faster.
>
>Ed "Sheepish" Poor
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at Wikipedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>
>
>
>
A dumb suggestion:

Temporarily, set the code to parse each page _twice_ (or N times)
instead of once, and see if it makes things any _slower_, and if so, how
much.

This should give you a good way of estimating the current slowdown,
without writing much code. Then you can estimate the possible speedup,
and whether it's worth the effort.

-- Neil


from_name: Brion Vibber

body:
On Wed, 25 Feb 2004, Nick Reinking wrote:
> Sorry to be a balloon burster.  ;)  Do we have any recent profiling on
> the code that shows where the bottleneck is?

E23 allegedly has been working on profiling code, but I've not played with
it in a long time so can't say what results look like.

Last time we did profiling, the Prime #1 Enemy was
OutputPage::replaceInternalLinks(). The rest of the page parsing was zippy
fast even with a hojillion passes.

This requires splitting up the page, identifying links, normalizing
titles, checking lookup tables for page existence, and generation of
output links. Make it fast and you win a prize!

>  I imagine most of the time
> is spent poking about in the database.  If that truly is the case,
> developer time would best be spent trying to maybe optimize the database
> layout or adding support for a faster database...

That's what the next revision will concentrate on: cleaning up the schema,
moving the large data blobs out of the most-queried tables, etc.

Note that page parsing time is largely separate from (though can be slowed
down by locking or disk churning due to) database slowness. But an
overloaded database does slow everything down and makes people
very unhappy.

-- brion vibber (brion @ pobox.com)


from_name: David Gerard

subject: [WikiEN-l] Paul Vogel and anon IDs

body:
See

http://en.wikipedia.org/wiki/Wikipedia:Conflicts_between_users#Paul_Vogel/65.125.10.66/24.45.99.191/216.99.245.171

He's coming in from three IPs and putting the same bit of spam into
a set of articles and their talk pages (and those of anyone who
reverts the spam).

He intends to continue however possible:

http://en.wikipedia.org/w/wiki.phtml?title=Talk:White_supremacy&diff=2458552&oldid=2458453

"WE can revert until the cows come home as long as a NPOV is not being
maintained regarding this strictly Marxist-PC POV propaganda article."

At what point should an anon user be blocked for spam? Is there a
measure of what's spamming on Wikipedia?

(And I am following bcorr's example and trying to keep reverts to
no more than three per article.)

- d.


from_name: Peter Jaros

subject: [WikiEN-l] Re: recipes

body:
On Feb 24, 2004, at 11:51 PM, Ray Saintonge wrote:

> Peter Jaros wrote:
>
>> Giving a recipe for a particular chocolate cake would not serve to
>> describe chocolate cake.  If one recipe was particularly famous,
>> however, it might merit its own section (or possibly article; I'd
>> like to try *that* cake) where the recipe *would* be descriptive.
>> It's a subtle distinction, but an important one.  It comes through to
>> readers, if only in terms of a sense of the style.
>
> That's very patronizing of you.

Sorry, I worded that poorly.  What I meant that the distinction may not
jump out at casual readers, but it sounds better nonetheless.  As
analogy, using the wrong word in a sentence and making the sentence
meaningless is obvious to even a casual reader, while using casual
language in a formal setting is often "felt" while not directly
noticed.  It can take a bit of working with a sentence to figure out
what in it sounds too casual (or too formal, or awkward, etc.).

Peter

                                  -- ---<>--- --
                        A house without walls cannot fall.
           Help build the world's largest encyclopedia at Wikipedia.org
                                  -- ---<>--- --


from_name: Ivan Krstic

subject: [Wikitech-l] Request

body:
This should not be hard to do. On the other hand, for the search you
listed below, Yahoo notably fails to produce a link to [[Thomas
Jefferson]] in *any* of their results (not just the first 20 - the link
is simply not there!), whereas it is the first result on Google.

Cheers,
Ivan

Jimmy Wales wrote:

> How quickly can we add a "Yahoo" searchbox to the "Full text search
> has been disabled temporarily" page?
>
> Yahoo has an 'advanced search' capability that is exactly like Google's
> for restricting a search to a domain:
>
> http://search.yahoo.com/search?x=op&va=Thomas+Jefferson&va_vt=any&vs=en.wikipedia.org
>
> ...for example.
>
> This is a request from Yahoo that I'd like to rush to accomodate, as
> they are showing lots of WikiLove toward the project of late.
>
> --Jimbo
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>


from_name: Hr. Daniel Mikkelsen

body:
On Wed, 25 Feb 2004, Poor, Edmund W wrote:

> As a programmer with well over a quarter century of experience, I
> applaud this effort by Nick to identify and slay the "dragon" of
> N-squared performance.
>
> When a process on a file takes time proportion to the file size, we call
> that N. When time is proportion to log N, we call that log N performance
> (quicksort, which uses a partition scheme and then sorts the partitions,
> has log N performance).
>
> A process whose elapsed time grows in proportion to the SQUARE of the
> file size is out of control! It's called an N-squared or N^2 process,
> and is to be avoided like the plague. Insertion sort and Bubble sort are
> examples, and have long been shunned for all but small numbers of items.

I should point out that average article size isn't growing, at least not in any
significant sense.

So on the larger scale, we have N performance.

(I'm not taking into account the fact that average size might conceal much
larger differences in performance because of the N^2 parser. But it's still
only the number of articles that's "out of control" here.)

-- Daniel


from_name: Evan Prodromou

subject: [Wikitech-l] Unbelieveable 1.1.0

in_reply_to:
<c1hd78$8gc$1@sea.gmane.org> (misterredtape@yahoo.com's message
	of "Tue, 24 Feb 2004 21:53:10 -0800")

body:
>>>>> "c" == ciaran  <misterredtape at yahoo.com> writes:

    c> I really wish I hadn't "upgraded" to this recommended
    c> version. But I won't go into all the issues here.

...just quickly insult the people who made the software for you to
use, then ask for their help again.

    c> One question: The status of links (broken, existing) NO LONGER
    c> UPDATE on any Wiki posts.

Double-check that this is actually the case. The default MediaWiki
color for stub links and the default browser color for visited links
is really similar.

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


from_name: Fred Bauder

subject: [WikiEN-l] Plautus

body:
I didn't actually fall down and roll on the floor, but LOL.

Don't worry, we can do the job.

Fred, arbitration committee member

> From: erik_moeller at gmx.de (Erik Moeller)
> Reply-To: English Wikipedia <wikien-l at Wikipedia.org>
> Date: 26 Feb 2004 01:39:00 +0100
> To: wikien-l at wikipedia.org
> Subject: Re: [WikiEN-l] Plautus
>
> Jimmy-
>> In the meantime, show him love.  Love is the only hope for us all.
>> If that doesn't work, well, at least we tried.
>
> Plautus is not reformable. He is a mentally unbalanced, paranoid
> delusional individual. The evidence here is about as clear as it can get.
> There is a discussion / evidence page at
> http://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Plautus_satire
>
> In an informal poll, 23 users have expressed that they want Plautus to be
> banned.  3 or 4 users currently think that he can be reformed.
>
> This situation is much clearer than it was with Clutch, and Clutch was
> banned.  It is much clearer than it was with Helga, and Helga was banned.
> It is much clearer than it was with Lir, and Lir was banned.
>
> I am all for due process. But this is not a case for mediation. I am
> beginning to doubt the capabilities of the arbitration committee. If they
> can't see that a user who writes messages like "UNBAN ME YOU FUCKING
> IGNORANT ASSHOLE" is a candidate for a ban, then they should not be
> allowed to make such decisions in the first place.
>
> We need quicker and more effective action against policy violations, or
> more users will be driven away in disgust. Wikipedia is a natural
> attraction point for cranks and crackpots. If you want to run an asylum,
> Jimbo, you should say so upfront. Otherwise we should refer these
> individuals to the proper institutions.
>
> Regards,
>
> Erik
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


subject: [Wikitech-l] Request

body:
>>>>> "JW" == Jimmy Wales <jwales at bomis.com> writes:

    JW> This is a request from Yahoo that I'd like to rush to
    JW> accomodate, as they are showing lots of WikiLove toward the
    JW> project of late.

They are?

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


references:
<E506B3FF6BC1254C9AC1B948C380BC2801FBB33C@sm-nyny-xm05.nena.wdpr.disney.com>
	<	> <403CD7DC.9020802@tonal.clara.co.uk>
	<c1j8c7$lev$2@sea.gmane.org>

body:
Wikimedia developers <wikitech-l at Wikipedia.org> writes:
>This isn't actually quite so bad an idea; this could be done for about a
>day to gather the necessary data. However, it *only* tells us how much
>of the performance is eaten up by the parser. It doesn't really tell us
>anything else. Our biggest problem is most likely not the parser.

To test if resolving internal links is a big performance hit, create two
pages, of roughly the same size, one with a large number of internal
links, and one with a large number of external links, which require no
database work.

You might want to create another page with *undefined* internal  links, to
test if there is some strange database problem.

Can you time processing of an individual page rendering?

Nick Pisarro


from_name: Delirium

subject: [WikiEN-l] Plautus

body:
Jimmy Wales wrote:

>Love is the only hope for us all.
>
>
Jimmy Wales: Bomis owner by morning, benevolent dictator by afternoon,
preacher by night.  :-)

-Mark


subject: [WikiEN-l] Paul Vogel and anon IDs

body:
Jimmy Wales wrote:

>The (in my opinion, disgusting) point of view expressed in the quote
>is of encyclopedic interest because it *is* a point of view held by at
>least some people who take action in the world, action that should
>concern us all.
>
>
It's also distinctive because white supremacy is agreed with by few (if
any) non-whites, but there are some non-whites who agree with the
doctrine that people of different races should live separately from each
other ([[black separatism]], for example, pretty much necessarily
implies [[white separatism]], since you can't have the one without the
other).  So they should be treated separately.  Or, alternately, in one
article about "Opposition to racial integration" or something of that
sort, detailing the (fringe) separatist views in both the white and
black communities.

-Mark


subject: [WikiEN-l] Plautus

body:
Erik Moeller wrote:

>Lee-
>
>
>>We can't decide whether somebody is a cadidate for a ban unless somebody
>>asks us to decide it, you know.
>>
>>
>
>No. You only accept cases for arbitration unless Jimbo explicitly refers
>them to you. This should be changed immediately. Jimbo is not involved
>enough in the day-to-day workings of the community to make these referral
>decisions.
>
>How fast can you fix that? If we are talking about weeks rather than days
>it's time to return to vigilantism.
>
>
 From my understanding we're essentially at a "good enough" working
draft of policies, which should be available in short order.  I believe
the new procedure will be essentially "ask for arbitration, and if 4
members of the committee agree, the case is heard".  There's more
explained in the policy, which I don't think has been posted yet (unless
I just can't find it), but the gist of it that normally only cases that
have had some attempt to mediate will be heard, but that's decided on a
case-by-case basis (we're not going to force people to go through
mediation that's obviously pointless from the start, because that just
wastes the mediation committee's time, and turns them into a waypoint on
the road to banning, while they're supposed to be a problem-resolution
committee that makes bans unnecessary).

-Mark


from_name: ciaran

subject: [Wikitech-l] Re: Unbelieveable 1.1.0

body:
Hello. I have further isolated this issue. Of course, it may be some
weird manifestation of Bug ID 802814
(http://sourceforge.net/tracker/index.php?func=detail&aid=802814&group_id=34373&atid=411192)...
but I am not sure.

Brion Vibber said the following on 2/25/2004 12:47 PM:

> Probably nothing to do with memcache, as memcache is not used for links
> in any way at present. Note that problems with link updates can be
> caused by errors that occur at save time, which may be hidden by the
> subsequent HTTP redirect to view the page. Try disabling the redirect
> for debugging purposes. (Grep for 'Location:' and comment out the
> header() call including it to disable automatic redirects.)
Perhaps the errors below are relevant (all other warnings occur during
page loads for all pages and they are attributed to OutputPage.php and
Setup.php). I have taken them from my php error log as suggested.

---
C:\DRIVES\IMAGO\PUB\public_html\www\yotz\wiki\LinksUpdate.php on line 230
[25-Feb-2004 19:03:45] PHP Notice:  Undefined variable:  fname in
C:\DRIVES\IMAGO\PUB\public_html\www\yotz\wiki\LinksUpdate.php on line 246
[25-Feb-2004 19:03:45] PHP Notice:  Undefined variable:  fname in
C:\DRIVES\IMAGO\PUB\public_html\www\yotz\wiki\LinksUpdate.php on line 247
[25-Feb-2004 19:03:45] PHP Notice:  Undefined variable:  fname in
C:\DRIVES\IMAGO\PUB\public_html\www\yotz\wiki\LinksUpdate.php on line 250
[25-Feb-2004 19:03:46] PHP Notice:  Undefined variable:
wgCommandLineMode in
C:\DRIVES\IMAGO\PUB\public_html\www\yotz\wiki\Setup.php on line 87
---

> Are you using MySQL 3.x? If so, did you put $wgEnablePersistentLC   =
> false; into LocalSettings.php?
>
> If not, could you check that the linkscc table is present?
The linkscc table is present. I am running mySQL 4.0.14 on Apache 2.0.47
  on a Windows XP-SP1 machine.

> Can you confirm that links are not being updated, rather than cached
> pages not being updated?
I have further established that links from the $wgSitename and
$wgSitename_talk namespace (only) do not update. I have this variable
set in LocalSettings.php and $wgMetaNamespace set to FALSE (in the same
file).

>
> Can you check your Apache error log for PHP error messages? Is PHP
> configured to log error messages? What version of PHP are you running?
PHP 4.3.2.

This is not a cache issue; I am running Firefox 0.8 in both cache (25MB)
and no cache modes and have cleared my cache on several occasions to
verify the link status. If I edit the offending page (the one displaying
the red links) and save it, the links update.

Thanks.

ciaran


subject: [Wikitech-l] Re: Unbelieveable 1.1.0

body:
Erik Moeller said the following on 2/25/2004 12:49 PM:

> You could try
> $wgCachePages=false;
> in LocalSettings.php. Does that help?
Browser caching is the first thing I checked. I set this variable in
LocalSettings to make sure, but the issue was unaffected. Please see my
reply to Mr. Vibber's post.

> Are you logged in / logged out? Which browser are you using? Is your wiki
> public somewhere?
I am logged in, using Firefox 0.8 on Windows XP with zero cache. My wiki
is at http://yotz.zeromass.org/wiki (you left a message on it one time :)

Try editing the sandbox and then return to the main page. The sandbox
link does not update.

Thanks.

ciaran


subject: [WikiEN-l] I like Plautus

body:
Plautus adds a lot of bullshit to the wikipedia, but
he also has a lot of "fringe" sources to cite. For
instance, he apparently thinks that the Columbia Space
Shuttle was shot down by a US missile-defense laser;
likewise, he thinks that tornados generate some kind
of plasma.

Now, it didn't take me long looking at yahoo to see
that Plautus may love conspiracy theories; but so do a
lot of other people. There are 65,000 websites on the
internet which discuss whether, or not, Columbia was
shot down.

In short, Plautus is adding the kind of information
which the Wikipedia should contain. I will agree that
this information should not be presented as NPOV fact,
it most certainly should be presented with an "experts
tend to disagree" disclaimer -- however, it should NOT
be deleted.

People are deleting Plautus' contributions which,
while they should be edited, are valid enough that
they should not be deleted. If Plautus gets upset over
the deletions, it is entirely understandable -- he is
being treated poorly, and if anyone should be banned
it is those who delete his text while hurling insults
at him.

People that disagree with Plautus should edit for
NPOV, they should not delete and censor him.

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools


from_name: Matthew Woodcraft

subject:
[WikiEN-l] Re: I think I can make it now,
	the pain is gone (was: I'm mad as hell,
	and I'm not gonna take it any more)

body:
Poor, Edmund W wrote:
>Remember when it took a long, soul-seaching vote on this mailing list
>for each new sysop?

Votes? I don't, no. When was that?

What I remember is

"I will give it out more or less willy-nilly to anyone who I know"

and

"Anyone else who wants sysop, just email me"

-M-


from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Two projects I'm exploring

body:
On Wed, Feb 25, 2004 at 09:17:09AM -0500, Nick Pisarro wrote:
> There are two projects that I am exploring that might make mediawiki more
> robust in handling the emmense load being placed on it.
>
> One, is a one or two pass wiki parser. The current parser, which performs
> dozens of passes, probably degrades by the square of the file size. I have
> added some thoughts to http://meta.wikipedia.org/wiki/One-pass_parser
>
> Storing diffs in the 'old' table. This would not affect performance,
> except when loading or comparing old revisions, but could drastically
> reduce the size of the database, which has to benefit how manageable it
> is. There already is a differencing engine in the source, though I'm not
> sure how reliable it is--it may also degrade by the square of the file
> difference. Here too, a sequence of diffs can be merged in one pass.
> Having written such code in the past, I plan to create a write up
> exploring this idea. Has this idea been discussed amongst the developers?
> What are the gotcha's?

No need to use insecure C/C++.
I have made a prototype in (ocaml)lex/(ocaml)yacc
(http://meta.wikipedia.org/wiki/Wikipedia_lexer).

It's one pass, extra fast, 100% secure, XHTML-clean, and more DWIM than current one.
The downside - it's not finished.


from_name: Erik Moeller

subject: [Wikitech-l] Unbelieveable 1.1.0

body:
ciaran-
> I really wish I hadn't "upgraded" to this recommended version. But I
> won't go into all the issues here.

Please do. That's the only way we can fix things.

> One question: The status of links (broken, existing) NO LONGER UPDATE on
> any Wiki posts. Does anyone know why this is?

You could try
$wgCachePages=false;
in LocalSettings.php. Does that help?

Are you logged in / logged out? Which browser are you using? Is your wiki
public somewhere?

Regards,

Erik


from_name: Timwi

subject: [Wikitech-l] Re: Image thumbnail problem

body:
Nils Kehrein wrote:

> the thumb creation is a bit curious:
> The thumbnail of a 14 KB PNG file is more than twice as large as the
> original image. Just have a look at it:
> http://de.wikipedia.org/wiki/Dune_II
> And 36 KB only for a 180 x 112 PNG is more than strange...

The reason for this is that your original image(s) is/are 8-bit
(256-colour paletted), while the auto-generated thumb-nail(s) is/are
24-bit (RGB-channel true colour).

In the original screenshot(s), using 256 colours makes sense if the
original game runs in that graphics mode anyway. However, the
scaled-down image(s) may (and do(es)) use sampling to reduce the amount
of loss of detail. Thus, using 24-bit RGB for it also kind of makes sense...

Greetings,
Timwi


subject: [WikiEN-l] Re: Plautus

body:
Sheldon Rampton wrote:

> Mark Pellegrini wrote:
>
>> Erik wasn't half right when he said Plautus is not reformable. He's
>> driving
>> away good users (Evercat and Finlay McWalter, just to name two), and
>> wasting
>> enormous amounts of contributor time. If Wikipedia is to become
>> popular on
>> the scale that many of us would like to see, the system needs to be
>> reformed. Just what does it take to get banned from this place?
>
>
> I think the underlying problem here is that Jimbo has stepped back a
> bit from his role as "benevolent dictator," referring this kind of
> decision to the arbitration committee. The problem is that the
> arbitration committee can't move quickly enough to deal with problem
> users like this one.
>
> One solution might be to designate a few trusted individuals as
> volunteer "judges" -- people to whom Jimbo in his capacity as dictator
> grants the authority to take action instantly, if they feel conditions
> warrant. The decisions of judges, of course, would be subject to
> review by the arbitration committee, and a judge who repeatedly abuses
> his authority would have it revoked.
>
> As a matter of policy, I think "judges" should not be allowed to
> simultaneously sit on the arbitration committee, so that we have some
> separation of powers.

Well, if this is done, I'm not sure why we'd really need the arbitration
committee.  Just to rubber-stamp judge decisions?

I'd feel a little more comfortable with a more streamlined arbitration
committee, which would basically be your judge idea but with multiple
people voting, and a lag-time of a few days (I don't think having
someone unbanned for, say, 3-4 days is the end of the world---it's the
2-3 weeks that's the problem).  But there's understandably tension
between "the arbitration committee should publicize at length the
rationale for its decisions" and "the arbitration committee should work
quickly".  There's only so many in-depth decisions that a group of
volunteers are going to write per week.

I hope the new edit-war policy will actually get rid of some of the
immediate problem, because anyone will be able to temp-ban people who
violate it.

-Mark


from_name: Ray Saintonge

subject: [WikiEN-l] I like Plautus

body:
Brian Corr wrote:

> Well maybe I'm in the minority, but I haven't been under the
> impression that the idea that the Star Wars lasers that can't even
> shout down test missiles were the cause of the Columbia disaster.

Those who had belonged to the same Russian gun club as Lee Harvey Oswald
considered him among the least competent marksmen in the club.  This
made it hard for them to believe that he could possibly have succeeded
in assasinating President Kennedy.

> And if we have to do is add that "experts tend to disagree" I think
> we'll soon have the Protocols of the Elders of Zion and Lyndon
> Larouche's conspiracy theories about the Queen of England and a load
> of other "crackpot theories" included in related articles as important
> pieces of info -- duly noting that they aren't NPOV facts.

The Protocols of the Elders of Zion comes up often enough in various
context that it needs an article.  Such an article needs to be fair, but
it also needs to include appropriate cautions.

Ec

>


subject: [Wikitech-l] Re: Two projects I'm exploring

body:
Nick Pisarro wrote:

> Speaking on a purely theoretical basis, an important thing to writing or
> tuning a program written in something like PHP is to understand what
> operations cost the most when executed in the particular language. Also in
> almost any language, repeatedly scanning, copying and concatinating large
> strings, like 100,000 byte articles is really costly. [.....]
>
> Database turning is quite important as well, though I get feeling you've
> been on top of that.

I find it *highly* interesting that so mnay people appear to think that
most of the performance problems are related to CPU usage rather than
database queries.

I can't claim to have a lot of experience with this, but this seems so
highly unlikely to me. Concatenating two strings, even kilobytes large
ones, it *negligible* compared to database queries that search the
entire 'old' table, or create temporary tables, or do ridiculous amounts
of joins and that stuff.

Since I'm afraid I don't know much about the database and the codebase,
I can't say a lot about this, but it seems highly foolish and very
detrimental to database performance to have separate 'cur' and 'old'
tables to serve entirely the same function, but then sticking the BLOB
that stores the actual article text in the same table as the article
meta information!

The database schema also uses far too many character strings (VARCHARs)
with indexes on them, in places where a numerical ID would do. "Hint
tables", such as "recentchanges" is one, are also often discouraged as
updating them on every edit is more costly than reading a
general-purpose table like... uhm... 'articlehistories', provided its
indexes are well-chosen.

But I've said all of this in August and September last year already.

Greetings,
Timwi


subject: [WikiEN-l] Crony capitalism

body:
I've noted this at Wikipedia as a Press Source

The CBC Newsworld <http://en.wikipedia.org/wiki/CBC_Newsworld> programme
Counterspin in a discussion on "Corruption and the Political Process"
made use of the Wikipedia definition of crony capitalism
<http://en.wikipedia.org/wiki/Crony_capitalism> , February 25.

It's interesting to see that we are being quoted by the primary Canadian
TV Network in the context of a current domestic political scandal. :-)

Ec


body:
Tomasz Wegrzanowski wrote:

> No need to use insecure C/C++.
> I have made a prototype in (ocaml)lex/(ocaml)yacc
> (http://meta.wikipedia.org/wiki/Wikipedia_lexer).
>
> It's one pass, extra fast, 100% secure, XHTML-clean, and more DWIM than current one.
> The downside - it's not finished.

I had to chuckle at your claim of something being "100% secure".


subject: [Wikitech-l] Request

body:
>>>>> "JW" == Jimmy Wales <jwales at bomis.com> writes:

    JW> And they're offering us a way to work directly with their new
    JW> system so that our content can be indexed more or less
    JW> realtime, i.e. we will give them an ability to grab an xml
    JW> feed.

We have an XML feed?

~ESP

--
Evan Prodromou <evan at wikitravel.org>
Wikitravel - http://www.wikitravel.org/
The free, complete, up-to-date and reliable world-wide travel guide


from_name: Magnus Manske

subject: [Wikitech-l] Two projects I'm exploring

body:
Ivan Krstic wrote:

> Now that Magnus mentioned it on Meta, I'm more inclined to ask: is
> writing Phase IV in C/C++ something that's being actively considered?
> Sure, it's an effort, but we're looking at - minimally - an order of
> magnitude improvement in performance. That does, however, raise the
> question of whether it's worth it to reinvent the wheel (Phase III is
> great software) for a problem that, in the foreseeable future, can be
> solved cheaply by throwing more processor horserpower into the mix, and
> by better caching.

The WINOR stuff on meta is old, but there's a "waikiki" subdir in the
"phase3" CVS, which contains C++ code for viewing *and* editing
(wiki)pedia pages, except for the latest stuff (new table and image
markup) and the math package.

I had once bundeled a free stand-alone (=no install) web server with an
executable made from this, for a on-CD-version of wikipedia. Even did a
German package of that, using sqlite as database.

So, less effort than expected ;-)

Magnus


from_name: bcorr at neaction.org

subject: [WikiEN-l] Plautus

body:
I appreciate Martin's email. I for one should have been more clear.

I had been taking individual action which I have found only marginally effective -- avoiding almost all contact with Plautus, while encouraging others to do the same, in hopes that a lack of interaction would be the "balm to heal the wounded spirit."

I should have asked, "When will the community take organized collective action to reduce the amount of time and energy which is being spent on what I believe are ineffective attempts by individuals to end or reduce the conflicts with Plautus?"

Having said that, I'm gratified that a number of people are still discussing this on the list, and though I fear that the current attempts may not work, I appreciate them and hope that Jimbo's assessment is correct.

Thanks,
Brian (Bcorr)

Quoting Martin Harper:
> Arno M wrote:
> > When will something be done?
>
> Brian Corr wrote:
> > Could someone give an update on a timeline for action?
>
> Something will be done about Plautus when you do something about
> Plautus. The timeline for action on Plautus is roughly:
> 1) You decide to act.
> 2) You act.
>
> Perhaps you meant to ask a different question?
> -Martin


subject: [WikiEN-l] Re: recipes

body:
On Feb 25, 2004, at 7:13 PM, Ray Saintonge wrote:

> I do get a little hot over these deletion issues. :-)

I understand.  I'm very much against deletion of recipes (and most
valid information), I just think we need to define the right place for
them.

> The expression that I found most patronizing  was "it might merit its
> own section".  I suspect that the subtleties between descriptive and
> prescriptive or between imperatiuve and indicative might not be
> meningful to the casual reader who wants to find out about a food
> and/or how to make it.  The technical detailsof chocolate cakes are
> not inherently controversial.  If different ways exist for making such
> a cake, the results of which is better can be entirely subjective.

My point was not about controversy or POV, just about appropriateness.
A drink recipe generally describes the drink, while a chocolate cake
recipe does not describe chocolate cake.  If a particular cake recipe
is famous and generally significant, I would say it warrants its own
section or article (regarding its significance, history, etc.).  There
the recipe *would* describe the topic (being the topic itself).

> Using a wrong word that gives the sentence a different meaning, rather
> than just making it meaningless can launch a discussion into a very
> different direction.  I confess to being quick to notice this kind of
> thing as I did with the earlier part of your previous post.
> "Proscriptive" and "prescriptive" have almost contradictory meanings,
> but grammaticaly can fit equally well into the same context.  I
> couldn't pass up the opportunity.

Huh.  I actually thought I was being correct by avoiding
"prescriptive".  Ah, well.  Touch?.  :)

Peter

                                  -- ---<>--- --
                        A house without walls cannot fall.
           Help build the world's largest encyclopedia at Wikipedia.org
                                  -- ---<>--- --


body:
Poor, Edmund W wrote:

> As a programmer with well over a quarter century of experience, I
> applaud this effort by Nick to identify and slay the "dragon" of
> N-squared performance.

As a computer science student in merely my first year, I apologise if
any of the following may come across as condescending or patronising,
but I feel that I should point out a few fallacies and inaccuracies in
your posting.

> When a process on a file takes time proportion to the file size, we call
> that N.

Firstly, you mean "linear", not "proportional" (nor do you mean
*"proportion"). (Actually, technically, you mean "asymptotically
linear", but I won't go into the difference now.) The correct notation
for this is O(n) (normally pronounced "order N"), with n being the input
size. See [[Big O notation]].

> When time is proportion to log N, we call that log N performance
> (quicksort, which uses a partition scheme and then sorts the partitions,
> has log N performance).

You are talking about O(n log n), not O(log n). In-place sort algorithms
cannot be faster than O(n log n); I could prove this right here, but I
can't be bothered.

[[Heapsort]] and [[Merge Sort]] are well-known examples of O(n long n)
sort algorithms. [[Quick Sort]], however, is O(n^2) (due to its
unfortunate worst-case scenario).

> A process whose elapsed time grows in proportion to the SQUARE of the
> file size is out of control! It's called an N-squared or N^2 process,
> and is to be avoided like the plague.

There are numerous situations where an O(n^2) algorithm is appropriate
to use. Quicksort, for example, is often applied where the worst-case
scenario is guaranteed to not occur. Sometimes there may not even be a
better algorithm.

You also appear to suggest that O(n^2) is the worst you can get;
Warshall's algorithm (which computes the transitive closure of a
directed graph) is O(n^3), and I think this is the fastest we can get
for that.

> Insertion sort and Bubble sort are
> examples, and have long been shunned for all but small numbers of items.

Insertion sort is *extremely* fast in situations where the data is
"almost sorted" and you are pretty sure the worst case never occurs (you
can get an average of O(n) operation). It has often been used to sort
the polygons you wish to render in a 3D scene by their distance from the
viewer; when you move the camera only slightly, these distances only get
out of order a little bit. (Of course, by now there are much more clever
algorithms for this sort of thing; just today we learnt one which
doesn't even require sorting the polygons.)

> Nick, if you and Magnus can pull this off, to Brion's satisfaction, you
> will gain the everlasting gratitude of the entire Wikipedia community.
> More power to you!

I completely agree. :-)

Greetings,
Timwi


subject: [Wikitech-l] DNS setup

body:
This may have got lost the first time, just pinging again. Currently
we're not able to make use of Coronelli's RAM for caching because the
DNS isn't pointing at it...

-- brion vibber (brion @ pobox.com)

On Feb 19, 2004, at 04:08, Brion Vibber wrote:

> Jason, could you take a look at the DNS setup as currently on zwinger?
> Right now I've got it limited to just wikipedia.org; we can add back
> the other domains once we're satisfied we know what we're doing. :)
>
> If it all seems well, can we get this duplicated on joey and set the
> domain record to point at us? The important thing is getting the
> double A record so both squid caches get used; it seems we're
> currently using RAM preferentially to disk, and there's only so much
> RAM available.
>
> Sample queries:
>
> $ dig @zwinger.wikimedia.org en.wikipedia.org
>
> ; <<>> DiG 9.2.2 <<>> @zwinger.wikimedia.org en.wikipedia.org
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55075
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
>
> ;; QUESTION SECTION:
> ;en.wikipedia.org.              IN      A
>
> ;; ANSWER SECTION:
> en.wikipedia.org.       3600    IN      A       207.142.131.235
> en.wikipedia.org.       3600    IN      A       207.142.131.236
>
> ;; AUTHORITY SECTION:
> wikipedia.org.          3600    IN      NS      zwinger.wikimedia.org.
> wikipedia.org.          3600    IN      NS      joey.bomis.com.
>
> ;; ADDITIONAL SECTION:
> joey.bomis.com.         142745  IN      A       130.94.122.196
>
> ;; Query time: 109 msec
> ;; SERVER: 207.142.131.234#53(zwinger.wikimedia.org)
> ;; WHEN: Thu Feb 19 04:01:03 2004
> ;; MSG SIZE  rcvd: 142
>
> $ dig @zwinger.wikimedia.org wikipedia.org any
>
> ; <<>> DiG 9.2.2 <<>> @zwinger.wikimedia.org wikipedia.org any
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2993
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; QUESTION SECTION:
> ;wikipedia.org.                 IN      ANY
>
> ;; ANSWER SECTION:
> wikipedia.org.          3600    IN      SOA     zwinger.wikimedia.org.
> brion.wikimedia.org. 2004021901 10800 3600 604800 7200
> wikipedia.org.          3600    IN      NS      joey.bomis.com.
> wikipedia.org.          3600    IN      NS      zwinger.wikimedia.org.
> wikipedia.org.          3600    IN      A       207.142.131.235
> wikipedia.org.          3600    IN      MX      10 mail.wikimedia.org.
> wikipedia.org.          3600    IN      MX      50 mormo.org.
>
> ;; ADDITIONAL SECTION:
> joey.bomis.com.         142897  IN      A       130.94.122.196
>
> ;; Query time: 251 msec
> ;; SERVER: 207.142.131.234#53(zwinger.wikimedia.org)
> ;; WHEN: Thu Feb 19 03:58:31 2004
> ;; MSG SIZE  rcvd: 208
>
> -- brion vibber (brion @ pobox.com)
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040225/6ffbbafb/attachment.pgp>


body:
Hr. Daniel Mikkelsen wrote:

> On Wed, 25 Feb 2004, Poor, Edmund W wrote:
>
>>As a programmer with well over a quarter century of experience, I
>>applaud this effort by Nick to identify and slay the "dragon" of
>>N-squared performance.
>>
>>When a process on a file takes time proportion to the file size, we call
>>that N. When time is proportion to log N, we call that log N performance
>>(quicksort, which uses a partition scheme and then sorts the partitions,
>>has log N performance).
>>
>>A process whose elapsed time grows in proportion to the SQUARE of the
>>file size is out of control! It's called an N-squared or N^2 process,
>>and is to be avoided like the plague. Insertion sort and Bubble sort are
>>examples, and have long been shunned for all but small numbers of items.
>
> I should point out that average article size isn't growing, at least not in any
> significant sense.

That isn't necessarily the point. If our parser is O(n^2), then this
means that the performance gets very bad very quickly as articles get
longer. This means that an O(n^2) algorithm is likely to take a lot
longer to parse an average-sized article than an O(n) algorithm.

However, I'm not actually convinced that our parser is O(n^2); if it
were to use only regexps, it is certainly O(n). Of course I know that it
doesn't strictly use only regexps, but I can't really think of anything
that even a naive programmer would put into such a parser that would
make it any worse than O(n).

Notice that this does not necessarily mean that our parser is efficient.
These O(n) and O(n^2) things are only time complexities, *not*
measurements of efficiency. In some situations, you can have a very good
O(n^2) algorithm (like Quicksort) that outperforms an algorithm with a
lower complexity class (like Mergesort, O(n log n)) for *certain* input
sizes. And as you mentioned, our articles have a pretty constant size.
The point in saying that something is O(n^2) *only* says that it will be
slower than O(n log n) or O(n) if you only make your input large enough.

> (I'm not taking into account the fact that average size might conceal much
> larger differences in performance because of the N^2 parser. But it's still
> only the number of articles that's "out of control" here.)

Again, I really don't think our parser is O(n^2). But I also really
don't think that this makes any difference. If we have O(n) with an
extremely bad constant factor, then we need to work on that constant
factor rather than on the time complexity class.

Timwi


body:
Neil Harris wrote:

> A dumb suggestion:
>
> Temporarily, set the code to parse each page _twice_ (or N times)
> instead of once, and see if it makes things any _slower_, and if so, how
> much.
>
> This should give you a good way of estimating the current slowdown,
> without writing much code. Then you can estimate the possible speedup,
> and whether it's worth the effort.

This isn't actually quite so bad an idea; this could be done for about a
day to gather the necessary data. However, it *only* tells us how much
of the performance is eaten up by the parser. It doesn't really tell us
anything else. Our biggest problem is most likely not the parser.

Timwi


from_name: Sheldon Rampton

subject: [WikiEN-l] Re: Plautus

body:
Mark Pellegrini wrote:

>Erik wasn't half right when he said Plautus is not reformable. He's driving
>away good users (Evercat and Finlay McWalter, just to name two), and wasting
>enormous amounts of contributor time. If Wikipedia is to become popular on
>the scale that many of us would like to see, the system needs to be
>reformed. Just what does it take to get banned from this place?

I think the underlying problem here is that Jimbo has stepped back a
bit from his role as "benevolent dictator," referring this kind of
decision to the arbitration committee. The problem is that the
arbitration committee can't move quickly enough to deal with problem
users like this one.

One solution might be to designate a few trusted individuals as
volunteer "judges" -- people to whom Jimbo in his capacity as
dictator grants the authority to take action instantly, if they feel
conditions warrant. The decisions of judges, of course, would be
subject to review by the arbitration committee, and a judge who
repeatedly abuses his authority would have it revoked.

As a matter of policy, I think "judges" should not be allowed to
simultaneously sit on the arbitration committee, so that we have some
separation of powers.

--Sheldon


body:
Brion Vibber wrote:

> On Wed, 25 Feb 2004, Nick Reinking wrote:
>
>>Sorry to be a balloon burster.  ;)  Do we have any recent profiling on
>>the code that shows where the bottleneck is?
>
> Last time we did profiling, the Prime #1 Enemy was
> OutputPage::replaceInternalLinks(). The rest of the page parsing was zippy
> fast even with a hojillion passes.
>
> This requires splitting up the page, identifying links, normalizing
> titles, checking lookup tables for page existence, and generation of
> output links. Make it fast and you win a prize!

My guess is that the slowest part of it is checking whether a page
exists, and if it does, checking its size (if the user has set the
preference that shows stubs in a different colour), because both of this
requires a database query.

These two things are therefore perfect candidates for memcaching (hint,
hint). Notice that we need to check if a page exists in several other
places too (hint, hint).

Timwi


body:
Nick Reinking wrote:

> I imagine most of the time
> is spent poking about in the database.

I totally agree.

> If that truly is the case,
> developer time would best be spent trying to maybe optimize the database
> layout or adding support for a faster database...

...or memcache more. :-)

Timwi


from_name: Martin Harper

subject: [WikiEN-l] Plautus

body:
Arno M wrote:
> When will something be done?

Brian Corr wrote:
> Could someone give an update on a timeline for action?

Something will be done about Plautus when you do something about
Plautus. The timeline for action on Plautus is roughly:
1) You decide to act.
2) You act.

Perhaps you meant to ask a different question?
-Martin


body:
Alfio Puglisi wrote:

> On Wed, 25 Feb 2004, Timwi wrote:
>
>>I find it *highly* interesting that so mnay people appear to think that
>>most of the performance problems are related to CPU usage rather than
>>database queries.
>>
>>I can't claim to have a lot of experience with this, but this seems so
>>highly unlikely to me. Concatenating two strings, even kilobytes large
>>ones, it *negligible* compared to database queries that search the
>>entire 'old' table, or create temporary tables, or do ridiculous amounts
>>of joins and that stuff.
>
> Well, this is easy to settle. If a developer posts somewhere the load
> averages of the DB server, web servers and squids, and can see what's
> most taxed.

Again, a better expert than myself should probably correct me if I'm
missing something, but I don't think you can compare CPU usage in one
system with I/O usage in another (how would you relate the two?). We
don't really want to know which of the two is used "more" (whatever that
might mean); what we really want to know is where things are blocking
(i.e. which of the two is "overloaded"). Hm, did that make sense?...

Timwi


from_name: Brian Corr

subject: [WikiEN-l] Paul Vogel and anon IDs

body:
Well, I took Jimbo's advice to heart and rewrote the article. It was only a
few minutes later that Paul Vogel edited it. To his credit (and I guess
mine too) he left most of what I wrote, although he did add in some stuff
about Palestinians and Jewish supremacy. Here's the difference between the two:
<http://en.wikipedia.org/w/wiki.phtml?title=White_separatist&curid=477296&diff=0&oldid=2533889>

However, the main problem -- and the same problem as before -- is that his
goal is to include two paragraphs about the supposed distinctions. All of
his previous edits to [[White separatist]] consisted only of those
paragraphs. This time he added them into the article, and also noted that
they are quotes -- he says "  According to a white separatist website:"

Anyway, I wanted to 1) let you know it was good advice and we've made some
progress it seems, and 2) ask some other folks to step in. I want to step
away from this day-long conflict.

Thanks,
Brian (Bcorr)

On 2/25/04, Jimbo wrote:
>I'm a little confused.  Why are people so adamant against having an
>article "White Separatism"?  Rather than banging our head against the
>wall fighting this guy, why not just make a better article?
>
>The junk this guy is inserting is junk.  It looks like a quote from
>someone, and if it is, then it's probably worth treating in a short
>article on the subject.
>
>There's nothing inherently wrong (that I know of) about having an
>article on "White Separatism" as distinct from (but related to) "White
>Supremacy".
>
>Here's a book about it:
>http://www.amazon.com/exec/obidos/tg/detail/-/0801865379/102-0949346-1338507?v=glance
>
>My dictionary (American Heritage) has separate entries for "White
>separatist" and "White supremacy".
>
>The (in my opinion, disgusting) point of view expressed in the quote
>is of encyclopedic interest because it *is* a point of view held by at
>least some people who take action in the world, action that should
>concern us all.


subject: [WikiEN-l] I like Plautus

body:
Well maybe I'm in the minority, but I haven't been under the impression
that the idea that the Star Wars lasers that can't even shout down test
missiles were the cause of the Columbia disaster.

And if we have to do is add that "experts tend to disagree" I think we'll
soon have the Protocols of the Elders of Zion and Lyndon Larouche's
conspiracy theories about the Queen of England and a load of other
"crackpot theories" included in related articles as important pieces of
info -- duly noting that they aren't NPOV facts.

Just my $0.02,
Brian (Bcorr)

Lir wrote at Wed Feb 25 19:43:44 PST 2004
>Plautus adds a lot of bullshit to the wikipedia, but
>he also has a lot of "fringe" sources to cite. For
>instance, he apparently thinks that the Columbia Space
>Shuttle was shot down by a US missile-defense laser;
>likewise, he thinks that tornados generate some kind
>of plasma.
[snip]
>In short, Plautus is adding the kind of information
>which the Wikipedia should contain. I will agree that
>this information should not be presented as NPOV fact,
>it most certainly should be presented with an "experts
>tend to disagree" disclaimer -- however, it should NOT
>be deleted.
[snip]


body:
On Wed, Feb 25, 2004 at 10:02:20PM +0000, Timwi wrote:
> Tomasz Wegrzanowski wrote:
>
> >No need to use insecure C/C++.
> >I have made a prototype in (ocaml)lex/(ocaml)yacc
> >(http://meta.wikipedia.org/wiki/Wikipedia_lexer).
> >
> >It's one pass, extra fast, 100% secure, XHTML-clean, and more DWIM than
> >current one.
> >The downside - it's not finished.
>
> I had to chuckle at your claim of something being "100% secure".

When talking about string parsing, it's usual to use "security" as a synonym of
"memory security". Ocaml is 100% memory secure. How memory secure is C we all know.

And more general absolute security is possible. In fact it's quite easy -
you just have to formalize semantics of the machine you'll be using to run
the program, write down the security properties, and prove that the program
satisfies these properties. It may require a couple orders of magnitude more
work than coding, but it's not a laughable matter.


from_name: Alfio Puglisi

body:
On Wed, 25 Feb 2004, Timwi wrote:

>I find it *highly* interesting that so mnay people appear to think that
>most of the performance problems are related to CPU usage rather than
>database queries.
>
>I can't claim to have a lot of experience with this, but this seems so
>highly unlikely to me. Concatenating two strings, even kilobytes large
>ones, it *negligible* compared to database queries that search the
>entire 'old' table, or create temporary tables, or do ridiculous amounts
>of joins and that stuff.

Well, this is easy to settle. If a developer posts somewhere the load
averages of the DB server, web servers and squids, and can see what's
most taxed.

Alfio


subject: [WikiEN-l] Plautus

body:
Jimmy-
> In the meantime, show him love.  Love is the only hope for us all.
> If that doesn't work, well, at least we tried.

Plautus is not reformable. He is a mentally unbalanced, paranoid
delusional individual. The evidence here is about as clear as it can get.
There is a discussion / evidence page at
http://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Plautus_satire

In an informal poll, 23 users have expressed that they want Plautus to be
banned.  3 or 4 users currently think that he can be reformed.

This situation is much clearer than it was with Clutch, and Clutch was
banned.  It is much clearer than it was with Helga, and Helga was banned.
It is much clearer than it was with Lir, and Lir was banned.

I am all for due process. But this is not a case for mediation. I am
beginning to doubt the capabilities of the arbitration committee. If they
can't see that a user who writes messages like "UNBAN ME YOU FUCKING
IGNORANT ASSHOLE" is a candidate for a ban, then they should not be
allowed to make such decisions in the first place.

We need quicker and more effective action against policy violations, or
more users will be driven away in disgust. Wikipedia is a natural
attraction point for cranks and crackpots. If you want to run an asylum,
Jimbo, you should say so upfront. Otherwise we should refer these
individuals to the proper institutions.

Regards,

Erik


subject: [WikiEN-l] Re: recipes

body:
Peter Jaros wrote:

> On Feb 25, 2004, at 7:13 PM, Ray Saintonge wrote:
>
>> I do get a little hot over these deletion issues. :-)
>
> I understand.  I'm very much against deletion of recipes (and most
> valid information), I just think we need to define the right place for
> them.
>
>> The expression that I found most patronizing  was "it might merit its
>> own section".  I suspect that the subtleties between descriptive and
>> prescriptive or between imperatiuve and indicative might not be
>> meningful to the casual reader who wants to find out about a food
>> and/or how to make it.  The technical detailsof chocolate cakes are
>> not inherently controversial.  If different ways exist for making
>> such a cake, the results of which is better can be entirely subjective.
>
> My point was not about controversy or POV, just about
> appropriateness.  A drink recipe generally describes the drink, while
> a chocolate cake recipe does not describe chocolate cake.  If a
> particular cake recipe is famous and generally significant, I would
> say it warrants its own section or article (regarding its
> significance, history, etc.).  There the recipe *would* describe the
> topic (being the topic itself).

I get the impression now that you blindly walked into an old war, only
to realise that bullets were flying in every direction.  The Battle of
Recipes was only one episode. :-)

The war is between two competing visions of Wikipedia.  One side, the
"deletionists", believes in deleting material which they consider to be
diminishing the reputation and authoritative quality of Wikipedia.  The
other side, the "inclusionists", believes that the purposes of Wikipedia
are better served by having articles in an ever expanding sphere of
knowledge defined in the broadest terms, even if it is in subjects that
others may find trivial.  I am clearly in the latter camp.

I don't work much at Wikibooks, so I am in no position to comment on its
policies.  Producing a cookbook seems well within its mandate.  It would
also seem to me that it would approach a subject in a broader, more
systematic way.  In the course of doing that it should be free to copy
any recipe from Wikipedia that it sees fit.  I even think that Wikibooks
might be a good place for starting the "1.0" project for a stable
printed version of Wikipedia that proponents prefer to only talk about.

If a duplicate os a recipe remains o Wikipedia, no harm is done, and
perhaps when the cookbook in Wikibooks is recognized as a serious
project people won't mind replacing the chocolate cake recipe in
Wikipedia with a statement like, "For a chocolate cake recipe see
[[Wikibooks:Chocolate cake]]", but until then attempts to remove them
will only cause arguments.

Ec


subject: [WikiEN-l] Plautus

body:
Lee Pilich wrote:

> At 02:51 26/02/2004 +0100, Erik wrote:
>
>> Lee-
>> > We can't decide whether somebody is a cadidate for a ban unless
>> somebody
>> > asks us to decide it, you know.
>>
>> No. You only accept cases for arbitration unless Jimbo explicitly refers
>> them to you. This should be changed immediately. Jimbo is not involved
>> enough in the day-to-day workings of the community to make these
>> referral
>> decisions.
>>
>> How fast can you fix that? If we are talking about weeks rather than
>> days
>> it's time to return to vigilantism.
>
>
> Well, I can't say how long it will take, because I simply don't know,
> but I sorely hope it will indeed be days rather than weeks. If we're
> not in a position to decide on hearing cases directly (ie, not through
> Jimbo) by this time next week then I'll be disappointed.
>
> The problem is that we're all volunteers, and we have other
> committments. I've been very pressed for time recently and so unable
> to take part in the discussion much, so it's not really fair for me to
> criticise the slowness of the process. I honestly believe that the
> arbitrators as a whole are going as fast as they can.

I can't understand why accusers are so impatient about getting results
from the arbitration committee.  One week would not be unduly long.
 Impatence should perhaps be taken as evidence that diminishes the
impatient person's case.  Impatience puts unfair pressure on volunteer
arbitrators.

Ec


from_name: Anthere

subject: [Wikipedia-l] Re: great news!

body:
It is really really great. I am very happy for you :-)
Good luck with the work :-) (I mean...the newbies and such ...)

ant

Kurt Jansson a ?crit:
> Yesterday there was an article about Wikipedia in Spiegel-Online, the
> biggest German online news-magazine (30 million visits/month), and I'm
> sure we got more new German Wikipedians yesterday than ever before.
>
> Through this article the TV took notice of us, and so there will be a
> feature (right word?) about us in the "Tagesthemen" at 22:30 (ARD). I
> think this is really great news.
>
> Thanks to all the people who keep the site running, the increase of
> visitors after the Spiegel-Online article went online was quite
> impressive, but the servers seem to handle it without problems.
>
> Our reader love us, the media loves us, at the moment I'm quite happy
> and I know I'm not alone with this feeling. This is a great project, and
> everybody can be proud to be part of it.
>
> Kurt
>