from_name: Nikola Smolenski

body:
On Monday 12 January 2004 13:04, zero 0000 wrote:
> I propose that for particularly problematic topics
> there are two versions.
> One is the "official version" which is
> write-protected.  The official
> version is what readers get when they click on links.
> The other is the
> "draft version", which can be editted.  Then there is
> some standard
> procedure (a committee?) by which the draft version
> can be copied to
> the official version.

I don't think that it should be done because I think that it could not be
ensured that the committees assembled for that purpose will be neutral.


list: wikien-l

source: pipermail-mbox

from_name: Anthere

subject: [WikiEN-l] Re: I am resigning if this goes on

body:
Oh; we were just having similar thoughts somehow :-)
Just not the same conclusions.
You have my support to remove any not-so-useful comment, just as we
would do on a talk page.

Poor, Edmund W a ?crit:
> If people continue to make personal remarks, I am going to resign as
> Wikien-l administrator. I am tired of all the bickering and pointless
> arguments.
>
> Ed Poor, aka Uncle Ed


from_name: Rick

subject: [WikiEN-l] User:Annek

body:
You might also want to check out User:LizardKing's Talk page, in which he referred to TUF-KAT as "you pellow-biting imbecile."  He also suggested contacting Annek to encourage him to continue his attacks.  (I assume "pellow" is supposed to be "pillow".)

RickK

---------------------------------
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040112/11e64082/attachment.htm


from_name: Martin Harper

subject: [WikiEN-l] "censorship"

body:
Dear Robert.

I see you have decided to accuse me of censorship again. I (and Danny, and
Viajero, and MIRV, and lots of other people) have already explained in great detail
the reason for mercilessly editing the text in question. However. I thought I might
usefully summarise the problem, with the help of an analogy.

The issue, as Ed Poor notes, is that generally we wish to state "X says Y about Z".
However, the removed text generally went further than that, essentially stating "X
says Y about Z and they meant W". This W is an interpretation, and as such it
expresses a point of view.

By analogy, I might write the following:

== Wikipedians who view democracy as hatred ==

Robert Kaiser, noted for his description of Wikipedia as a "home for lying, leftist anti-
Semites", has come out strongly against democracy. In a mailing list post, to wiken-l,
January 12 2004, he wrote that "Facts are not defined by votes. Only hatred is."

-----

This illustrates the key problem - that by taking words out of context and placing
them under a header that expresses an interpretation of those words, it is possible to
have text that expresses a point of view, even though the actual quotes are precise
and well-referenced. This is precisely the problem with much of the text in question.

However, on the topic of censorship, I see you decided to deleted the entirety of
"Support" section of the article on "alternative medicine". Given your new and heroic
stand against deleting dodgy text and in favour of fixing it, I trust that we shall see
you take a fresh approach on such issues in the future?

-Martin "MyRedDice" Harper


from_name: Tucci

subject: [WikiEN-l] Re: User:Annek

body:
--- Menchi <ebeins at hotmail.com> wrote:
> Obviously the reincarnation of another vandal who
> you admonished. Think
> hard.
>

I don't generally get involved in arguments.  Lately,
Lizard King has been an exception after the
Talk:Cronus debate concerning his sketch, which has
now moved on to his drawing of Bigfoot at
Talk:Bigfoot.  Since posting my original message to
the mailing list, Lizard King changed my comments on
Talk:Bigfoot to make it appear as though I liked his
sketch (I don't) and that I found Bigfoot sexually
appealing (I don't).  Lizard King and Annek both
changing my words concerning my sexual preferences in
the same day is suspicious, but could just be a
coincidence (he's denied having any sock puppet
accounts on his talk page, but this seems highly
unlikely given the number of unheard-of users who like
his sketch chiming in at Talk:Bigfoot).

I've never been in any real edit war, except for
Michael and this doesn't seem like his style.  I've
been in a few arguments that have gotten heated, but
not many and few of our endlessly reappearing users.
Lizard King is the only one that seems a possibility
to me, but Annek was making edits long before Lizard
King was around.  I also checked Annek's
contributions, and it doesn't seem like I ever edited
anything he wrote, though MyRedDice and SalsaShark
reverted some changes he made to [[nigger (word)]] and
[[wigger]].  I wasn't aware I had any enemies on
Wikipedia (except Michael, whom I haven't even seen in
months) and I can't remember the last time I blocked
any IP (more than six or seven months ago, I'm sure).

TUF-KAT

P.S. Since I'm delurking myself anyway: not many
people have given any opinions concerning the
"artist's rendering" and taxobox at [[Bigfoot]].  I'm
opposed to both, especially the latter, but my
feelings about the sketch are actually mixed -- I'm
against it, but it doesn't bother me terribly and I
wouldn't normally get involved, except I already was.
Some other thoughts there would be nice.

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus


subject: [WikiEN-l] User:Annek

body:
--- Rick <giantsrick13 at yahoo.com> wrote:
> You might also want to check out User:LizardKing's
> Talk page, in which he referred to TUF-KAT as "you
> pellow-biting imbecile."  He also suggested
> contacting Annek to encourage him to continue his
> attacks.  (I assume "pellow" is supposed to be
> "pillow".)
>
> RickK

Yes, this makes it seem much more likely that Annek
reincarnated himself as Lizard King to upload his
sketches, I suppose anticipating opposition (though
Annek hasn't chimed in supporting Lizard King).

TUF-KAT

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus


from_name: John C. Penta

subject: [WikiEN-l] On the Middle East, on the Jimbo-RK-Danny dispute, etc.

body:
All,

    I am not traditionally one who posts to this list. I usually watch, read, and watch some more. I do not, typically, edit either, though I will contribute to Talk pages; I simply do not feel my writing skills are up to the task.

    However, I am forced to take a stand on this issue, and speak up.

1. I generally am somewhat laid-back when it comes to Wikipedia; I could normally care less. However, as I believe has been recognized, consciously or unconsciously, by the combatants (all of them) in the Middle East articles, WP is becoming, online, a significant source of information.

It is no longer just our plaything, our project. It is a potential part of the information battlespace. The same as TV, as radio, as the newspaper, as paper encyclopedias (which DO have political slants). The same as academic syllabi. The same as any means of disseminating information or opinions. It is no longer just the contributors'...It's a battleground, and will be (heck, probably is already (in far less obvious guises than you may expect)) used as such by communications elements on both sides.

This will not change, and will likely become an issue for other controversial topics as well.

2. That being the case, I've come to the sad conclusion that maybe Wiki should just officially avoid the topic. Stay silent. It'd be sad, but perhaps necessary.

3. On the Jimbo-RK-Danny triangular dispute (including all of the others on all sides)... Cease fire? Agree to disagree. The next time this happens, make it really simple.

Ban both sides. One warning, then down comes Mr. Boot.

4. In terms of audiences: I have to agree with mav here. Wiki-En's primary audience is and must be native English-speakers. That doesn't mean American, European, Indian, Filipino, Martian, Plutonian, or Vulcan. It means people who speak English as their native (and primary) language. Who may well not speak any other language. (In fact, who probably do not. I've found that knowledge of two or more langauges is primarily an attribute only of the intellectual; The average "man-on-the-street" is generally unlikely, anywhere, to speak or understand more than one language. Probably no more than 1 dialect of that 1 language, too.)

Respectfully,
John Penta


list: wikitech-l

from_name: Brion Vibber

subject: [Wikitech-l] Re: Secondary servers

body:
On Jan 12, 2004, at 16:23, Brion Vibber wrote:
> Our present alternatives for database duty are:

As a reminder, we're not talking here about future machines to get, but
about what's in the racks and online *right now*.

> * Carol (currently idle) with a SCSI drive that's too small for the
> whole database.

Ran memtester and managed to kill the poor dear. Carol initially had an
overheating problem and crashed soon after installation. Jason fiddled
with the case and placement to improve airflow, but unfortunately this
may not be enough. :(

Scratch Carol off the list for now. Carol's also got 4GB of RAM which
would be _very_ nice to have up and running, assuming it all works!

> * Susan (currently idle) with another IDE drive that's likely not the
> fastest.

Susan hasn't died during memory testing yet (yay). However it's a
smaller machine with only 512MB of memory as well as the ide disk. Not
ideal for database, though this might be sufficient to offload some
work.

I won't touch the databases just yet...

-- 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/20040112/01e68ee3/attachment.pgp>


subject: [WikiEN-l] "anti-Semitic"

body:
Dear Robert.

I see that you have decided to branch out from claims that I am "harrassing" and
"censoring" you and decided to move back to the familiar territory of accusing me of
being a Nazi and anti-Semite. Given that you have previously attacked the whole of
Wikipedia as being "a community of violent Jew haters", I don't suppose anyone will
pay any attention.

Nor am I surprised at such attacks, given that one of the first things you said to me
was that I was "engaging in neo-Nazi like revisionism" - completely without
foundation, of course. However, I was interested to read the following:

> (People imagined that it was I who wrote the analysis. Actually, it
> was written by someone else. I can forward you copy of the
> posting.)

> I am talking about very specific edits, which I can show you.

As I have commented before, I would like to receive this mythic analysis, which has
yet to be posted publically. I have asked before, but perhaps you forgot. Robert, if
you would forward me a copy I would be delighted to read it and take on board any
criticisms it makes of my words or actions. Not least, I would like an opportunity to
retract things I may have said too hastily, or clarify statements that I feel may have
been misinterpreted.

I would also like to appeal to anyone else who may have in their possession, or be
able to obtain, a copy of this apparently compelling analysis, to ask if they could
forward it to me, in strict confidence. You can email me at
wikipedia at myreddice.co.uk

Thanks,
-Martin "MyRedDice" Harper


from_name: Nick Hill

subject: [Wikitech-l] Secondary servers

body:
This would be cured by moving the database to solid state memory.
Mechanical media has a very long seek time and when many seeks are
required, become unreliable.

Either:
Run two MySQL instances, one starting after the finest grained database
files have been copied to ramdisk. Replicate database to a hard disk file.

Or
Install a solid state IDE disk. For example, a 4Gb Compact Flash card
has an IDE interface built in as part of the specifications. Access time
0.1ms comapred to mechanical 8.5ms. 85x faster. CF to IDE cables are
trivial and available.

To put it another way, you would need 85 mechanical drives to provide
the seek performance of a solid state equivalent.

Brion Vibber wrote:
> We really, really need to move the database back to a machine with a
> decent hard drive. The wikis are very sluggish, and a fair chunk of it's
> from waiting on the database.
>
> Ursula's sitting around with a 90% idle CPU, but everything's blocked on
> disk I/O to the point it's got a load average of about 16. At any given
> time from 8-20 processes are blocked and waiting. Operations that hit a
> lot of rows like history and watchlist are particularly badly hit since
> they don't play as well with caching.


from_name: Menchi

subject: [WikiEN-l] Re: Re: User:Annek

body:
If you think you don't deseve this defamation, you're right. If you think
the vandal needs a real reason to defame you, you are wrong. Vulcan logic is
not in the Dictionary of the Vandals. You needn't say something critical of
the vandal. If he doesn't like whatever you said or consider you
disrespectful of his "work", he'll find a way to defame/insult you. The Way
of the Vandal.

Do not worry about it too much. Well, a little bit is ok.

--
___________________________
Menchi


from_name: Camille Constans

subject: [Wikitech-l] Secondary servers

body:
On Mon, 12 Jan 2004 11:39:59 -0800
Brion Vibber <brion at pobox.com> wrote:

> Well, went ahead and turned on interrupt unmasking and 32-bit io. The
> numbers in vmstat don't look too much different yet, but we'll see.
>
> -- brion vibber (brion @ pobox.com)
>

On my IBM 80 Go, 7200 trs/mn

Before :  IO_support   =  0 (default 16-bit)
> hdparm -t /dev/hdd
> /dev/hdd:
>  Timing buffered disk reads:   82 MB in  3.05 seconds =  26.89 MB/sec

After : IO_support   =  1 (32-bit)
> hdparm -t /dev/hdd
> /dev/hdd:
> Timing buffered disk reads:   74 MB in  3.03 seconds =  24.42 MB/sec

No changes seen....

Shaihulud


from_name: Graham Burnett

subject: [WikiEN-l] filter

body:
>I'm applying a mailing-list filter to posts mentioning the word "N***".

Can we have one that filters the word "RK" as well????

Graham (Querus robur)

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.560 / Virus Database: 352 - Release Date: 08/01/2004


subject: [Wikitech-l] Secondary servers

body:
audin at okb-1.org wrote:

> 	Ramdisks have no place beyond MS/PC-DOS, Knoppix, and OS install
> floppies.  Why dedicate a gob of memory to a ram disk when you can achieve
> similar performance with the OS's caching facility while also allowing that
> memory to be conscripted for other uses should the need arise?

Caching algorithms tend to use a least recently used algorithm. When
larger blocks of data are read from storage, the least recently read
fine grained data is flushed.

The cost of reading fine grained data is very high. This cost can be
avoided by keeping fine grained data in ramdisk, unless some
prioritising can be set up to avoid the fine grained data being flushed
for much longer than the coarse grained data.

A 1Mb piece of data may take
Seek + Transfer = I/O cost
8.5ms + 20ms = 28ms

a 10K piece of data may take
8.5ms + 0.2ms = 8.7ms

We can calculate this in terms of I/O blocking cost per given data size:
10k chunks (fine grained - eg article database) cost 870ms/Mb
1Mb Chunks (Coarse Grained- eg program code, media files) cost 28ms/Mb

Fine grained data is far more I/O costly than coarse grained data.

Is there another way to prioritise the fine grained data other than
ramdisk? If so, this may be the key to a far more efficient system.

>
> 	Flash devices have rather serious write-cycle limitations.  As mysql
> does not do anything to avoid hot spots, such a setup would likely not last
> long.

We would need to know how hot the hotspots tend to be before
implementing such a solution. Typical r/w on modern flash tend to be
1m-10m cycles.


from_name: Alfio Puglisi

subject: [Wikitech-l] Secondary servers

body:
On Mon, 12 Jan 2004, Nick Reinking wrote:

>Hmm... 4GB Compact Flash cards would be:
>
>Too small (4GB is not enough space, we would need a couple hundred
>cards)

Wait a sec, those two hundreds cards total 800GB. Are you sure that
wikipedia needs that kind of storage? I thought that current articles are
a few gigs, and history a few tens of gigs.

>Too expensive (4GB cards cost approximately about $1100, or around
>$330000 for enough space)
>Too slow (fast access, but only a 5MB/sec read/write)
>Limit read/writes (they would last about one week, and need to be
>tossed out)

I agree, Flash cards are not OK for our needs. A server with lots of
RAM is much better. Geoffrin would be really optimal, if it worked :(

Someone mentioned $6K for Apple raid storage, but that price is not so
high: here at work we have some kind of raid NAS (half a terabyte I think)
that went for about $4K. So yeah, NAS can be expensive, a simple internal
SCSI raid like our current setup is enough, and with regular backups it
can be transferred to another machine in case of need (heck, that's what
Brion did multiple times in the last weeks if I am not mistaken, and
that's enough proof that it works).

Alfio


subject: [WikiEN-l] Re: Nix on Nazi talk

body:
good :-)

Poor, Edmund W a ?crit:
> I'm applying a mailing-list filter to posts mentioning the word "Nazi".
>
> Ed Poor
> Wikien-l admin


from_name: Pedro Fortuny

subject: [WikiEN-l] Nazi nazi NAZI

body:
* Poor, Edmund W <Edmund.W.Poor at abc.com> [2004-01-12]:
> Optim,
>
> The filter is much more sophisticated than this:
>
>  if (msg.indexOf("Nazi") > -1) {
>
> 	msg.reject();
>
>  }
>
> It's context-sensitive.
>

That was a good one, Ed. lol.

Pedro.

--
Pedro Fortuny Ayuso: http://pfortuny.sdf-eu.org
Colegio Mayor Pe?afiel, Universidad de Valladolid
C/ Estudios 6, 47005 Valladolid, Spain -->        www.cmpenafiel.org
pfortuny at sdf-eu.org                         Tfn. Nr. 34  983  298277


from_name: Peter Jaros

subject: [WikiEN-l] This is getting ugly

body:
On Jan 12, 2004, at 10:24 AM, Robert wrote:

> This is getting really ugly.

Agreed.  Definitely agreed

> A dozen people have nmade
> personal attacks on me, all of them falsely saying that I
> am making personal attacks.

Here's where it gets ugly, my friend.

> Then an obviously anti-Israeli crowd is trying to define
> reality by voting, and is deleting vast amounts of proven
> facts in order to promote pro-Arab POV.
>
> Facts are not defined by votes. Only hatred is.
>
> If the consensus is that Wikipedia should promote
> anti-Zionism, anti-Semitism, and hateful crowds ganging up
> on one user, then that is precisely the reputation that it
> will get offline.

You must see that you're perpetuating the ugliness as much as your
"attackers" (poor word choice of mine, but you know what I mean).  Of
course, the converse is true: your "attackers" are perpetuating the
ugliness as much as you.  It's just not necessary.

People have said things.  People have interpreted and misinterpreted
things.  It's done, it's happened, and it's now in the past.
Meanwhile, the *rest* of us are working on an encyclopedia.  If this is
a personal battle, I personally think you (very much plural) should
simply drop it.  If you wish to continue I would appreciate if it were
taken off-list.  These accusations and counter-accusations have no
place here.

That said, there *is* a substantive issue hidden in this mess.  The
NPOV of certain articles is being questioned.  Let's address that.
What has happened to the articles in the past does not matter anymore.
Remember, the page history may exist, but it's the latest revision that
counts.  Let's discuss what *is* there and what *should be* there.
Without accusing each other of anti-Anythingism.

We are a community.  We are based tightly around the encyclopedia, but
we are a community.  Anyone who is here to make offensive remarks or
accusations is in the wrong place.  #REDIRECT [[Usenet]].

That said, we must have to trust that others' remarks are not intended
as accusations or otherwise meant to offend.  If we don't give each
other the benefit of the doubt, we'll all end up, well, basically like
we are now: wrapped up in an unproductive argument over who said what
(or didn't say what).  In the worst case scenario, you take an insult
as constructive criticism.  Who cares?  If someone tries to hurt you
and you don't notice, the other person's comment will just fall flat on
it's face.  All the better.

Let's revive the substantive issues in an objective, fair, and, most
importantly, calm manner.  Please drop the rest, or, if you must, take
it off-list.  Thank you.

Concerned Wikipedian otherwise uninvolved in the matter,
Peter


from_name: Magnus Manske

subject: [Wikitech-l] Secondary servers

body:
Alfio Puglisi wrote:

> On Mon, 12 Jan 2004, Nick Reinking wrote:
>
>>Hmm... 4GB Compact Flash cards would be:
>>
>>Too small (4GB is not enough space, we would need a couple hundred
>>cards)
>
> Wait a sec, those two hundreds cards total 800GB. Are you sure that
> wikipedia needs that kind of storage? I thought that current articles are
> a few gigs, and history a few tens of gigs.
>
>>Too expensive (4GB cards cost approximately about $1100, or around
>>$330000 for enough space)
>>Too slow (fast access, but only a 5MB/sec read/write)
>>Limit read/writes (they would last about one week, and need to be
>>tossed out)
>
> I agree, Flash cards are not OK for our needs. A server with lots of
> RAM is much better. Geoffrin would be really optimal, if it worked :(

Here's a crazy thought: Is there a way to make a server identify itself
as a *harddrive* on the SCSI bus? If so, we could take a machine with
lots of RAM which does nothing else than holding most of the DB in cache
(cheaper and faster than Compact Flash:-) and occasionally write stuff
to its hard drives. Probably won't need much of a CPU, and maybe not
even SCSI drives, just cheap IDE ones, as all it does is caching.

Then, we could plug that thing into the "real" DB server, which just
sees a really fast HD.

Well, one can dream...

Magnus


subject: [WikiEN-l] A proposal to improve war-prone pages.

body:
On Jan 12, 2004, at 1:38 PM, Nikola Smolenski wrote:

> On Monday 12 January 2004 13:04, zero 0000 wrote:
>> I propose that for particularly problematic topics
>> there are two versions.
>> One is the "official version" which is
>> write-protected.  The official
>> version is what readers get when they click on links.
>> The other is the
>> "draft version", which can be editted.  Then there is
>> some standard
>> procedure (a committee?) by which the draft version
>> can be copied to
>> the official version.
>
> I don't think that it should be done because I think that it could not
> be
> ensured that the committees assembled for that purpose will be neutral.

Er, then who *would* be neutral?  Someone has to be, or we'll never get
anywhere...

Peter

---
Funding for this program comes from Borders without Doctors: The
Bookstore Chain That Sounds Like a Charity.
		--Harry Shearer, Le Show


subject: [WikiEN-l] Scanning VS. Reading

body:
On Jan 12, 2004, at 2:40 PM, Vicki Rosenzweig wrote:

> Sure, we should write so that the reader can learn something even if
> she
> only has time, or desire, to read part of the article. And yes,
> well-organized
> sections and headers are helpful. But if nobody is going to read
> something,
> I see no point in writing and publishing it.

Yes, people will read the details, but if we can make articles more
accessible to people looking for only a sense of the topic, as well as
people scanning a specific detail, all the better.

Peter

---
Funding for this program comes from Borders without Doctors: The
Bookstore Chain That Sounds Like a Charity.
		--Harry Shearer, Le Show


subject: [WikiEN-l] Reading Software

body:
On Jan 12, 2004, at 8:28 PM, Nikos-Optim wrote:

> I would like to find some way to
> incorporate some hidden punctuation into the articles,
> which will be used only by reading software but will
> be invisible to the user who reads the text on the
> screen or paper. Do you have any idea on this?

Easiest way is probably to have an equivalent to the "Printable
Version" link.  Users load the "Speakable Version", complete with
punctuation marked-up as hidden, and feed it to the reading software.
Voil?!

Peter

---
Funding for this program comes from Borders without Doctors: The
Bookstore Chain That Sounds Like a Charity.
		--Harry Shearer, Le Show


from_name: Gabriel Wicke

subject: [Wikitech-l] Re: Secondary servers

body:
On Mon, 12 Jan 2004 11:11:28 -0800, Brion Vibber wrote:

> If Geoffrin's not going to be up soon, and Pliny's still emitting
> spurious disk errors, what are our options out of the available
> machines?

How about installing Squid on one of the machines? That would take a fair
amount of load away. Is there a machine with some free Ram available?
Even installing Squid on larousse would do i guess. I've glanced over the
php code- there are mainly two header lines we would need to change to
activate this- we could start off with a 30 minute timeout for anonymous
users. Purging should get ready soon as well.

We can configure Squid depending on the available Ram- especially maximum
object size in Ram and replacement policy. This should catch most small
(=compressed html) files.

Let me know if you need help, i could help with that tomorrow.

--
Gabriel Wicke


subject: [Wikitech-l] Secondary servers

body:
On Mon, 12 Jan 2004, Magnus Manske wrote:

>Here's a crazy thought: Is there a way to make a server identify itself
>as a *harddrive* on the SCSI bus? If so, we could take a machine with
>lots of RAM which does nothing else than holding most of the DB in cache
>(cheaper and faster than Compact Flash:-) and occasionally write stuff
>to its hard drives. Probably won't need much of a CPU, and maybe not
>even SCSI drives, just cheap IDE ones, as all it does is caching.
>
>Then, we could plug that thing into the "real" DB server, which just
>sees a really fast HD.
>
>Well, one can dream...

Wouldn't the "harddrive" server be equivalent to the local RAM cache, only
accessed via the SCSI bus? it seems to me that it would work in the same
fashion - retrieve articles from the DB, cache them in RAM, and send them
over the SCSI bus - exactly what the actual server is doing. You're just
adding the RAM caches together, one local, one over a SCSI bus. Double the
RAM on the primary server, and you're better off :)  (I'm assuming that OS
and application RAM overhead are minimal, which is probably true on a 4GB+
machine).

Alfio


subject: [Wikitech-l] Secondary servers

body:
On Mon, 12 Jan 2004, Ricky Beam wrote:

>I currently have a $250 eurologic fibre channel shelf (FC7 or FC9) with
>dual power supplies and 7 146G seagate (300$ each) heating my apartment :-)
>The shelf is easy to find.  Wiki would want new drives vs. the OEM pulls
>I'm using which doubles the cost of the drives. (they aren't easy to find
>used anyway.)  That's just under 1TB.  Each drive can stream ~60MB/s.  Yes,
>EACH. (all the way to bus saturation: 2Gb/s)

Yes, if one needs throughput, IDE or SCSI will hardly matter, and the
former will be cheaper. But it seems that our disk subsystem is hampered
by latency - lots of small reads looking for DB indexes, articles, things
that got pushed out from the cache, all of them from multiple concurrent
threads. Short of a pure ramdisk, SCSI raid is still the leader in this
deparments :)

Alfio


subject: [Wikitech-l] Re: Secondary servers

body:
On Mon, 12 Jan 2004, Gabriel Wicke wrote:

>On Mon, 12 Jan 2004 11:11:28 -0800, Brion Vibber wrote:
>
>> If Geoffrin's not going to be up soon, and Pliny's still emitting
>> spurious disk errors, what are our options out of the available
>> machines?
>
>How about installing Squid on one of the machines? That would take a fair
>amount of load away. Is there a machine with some free Ram available?

It seems a good idea. It would eliminate the DB timestamp lookup for each
page request. But the purging code must be implemented, and that would
take time.

Alfio


subject: [Wikitech-l] Re: Re: Secondary servers

body:
On Mon, 12 Jan 2004 23:26:02 +0100, Alfio Puglisi wrote:

> On Mon, 12 Jan 2004, Gabriel Wicke wrote:
>
>>On Mon, 12 Jan 2004 11:11:28 -0800, Brion Vibber wrote:
>>
>>> If Geoffrin's not going to be up soon, and Pliny's still emitting
>>> spurious disk errors, what are our options out of the available
>>> machines?
>>
>>How about installing Squid on one of the machines? That would take a fair
>>amount of load away. Is there a machine with some free Ram available?
>
> It seems a good idea. It would eliminate the DB timestamp lookup for each
> page request. But the purging code must be implemented, and that would
> take time.

Should take an hour maybe- had a look at it today. The Squid could even
get installed before this, we would just need to set a relatively short
timeout for anonymous users. That's five lines of php to change.

--
Gabriel Wicke


from_name: Dan Miller

subject: [WikiEN-l] New deletion policy suggestion

body:
For those who haven't been following the discussion on
Talk: Votes for Deletion, I thought I'd drag this idea
into the light of debate:

I agree that the VfD process is overused; look at the
relatively high proportion of "keep" votes. Ideally,
only pages that are relatively clear-cut cases would
go here, with the rest being moved to cleanup or
elsewhere. But the WikiMoney plan would harm new
users, and also be quite complicated to use. Why not a
better plan, such as:

Before any page can be listed on regular VfD, it must
be listed on cleanup and left there for some time; I'm
thinking two weeks, but this is negotiable. After
that, it can be moved to VfD, and a vote can be held.
Of course, the regular candidates for speedy deletion
could go, and the copyvio delete page would be
unaffected. Not only would this solve the overuse of
VfD, it would also help stop the occasional listing on
VfD of copyvios. And, it could be accomplished by
simply placing a notice at the top of the VfD page,
rather than encumbering everyone with a complicated
system of WikiMoney, which might frighten newbies and
irritate old hands.

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus


from_name: zero 0000

body:
I'll make some brief remarks on the responses
to my proposal.

1. Viajero suggested that it needed software changes.
  While some software assistance would be nice,
  it can all be done with the present software.
  The official page would be, say, [[Arafat is fat]],
  and the draft page would be [[Arafat is fat
(draft)]]
  or maybe [[Arafat is fat/Draft]].

2. Nikola mentioned the partiality of the committee
  as an issue.  There need not be a committee,
  that is just one possible implementation.
  Another is that the protagonists agree amongst
  themselves when some draft is better than the
  official page and ask a sysop to do the copy.
  In any case, the current system is that the page
  contents are decided by the most persistent fanatic,
  and anything has to be better than that.

3. John suggested that Wikipedia should in fact
  drop some issues altogether.  This is actually
  close to the way I really feel about it.  My
  suggestion for a process change is merely my
  best idea on how to avert this step.  Whatever
  path is taken, the present system is the worst
  option.

Zero.

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus


subject: [Wikitech-l] Re: Secondary servers

body:
Gabriel Wicke wrote:

> How about installing Squid on one of the machines? That would take a fair
> amount of load away. Is there a machine with some free Ram available?
> Even installing Squid on larousse would do i guess. I've glanced over the
> php code- there are mainly two header lines we would need to change to
> activate this- we could start off with a 30 minute timeout for anonymous
> users. Purging should get ready soon as well.

Perhaps I will be burned at the stake as a heretic for this, but I am
not convinced squid proxies are the answer.

The delays in the wikiserver system are caused by waiting for I/O- the
time taken for mechanical devices to seek a particular block of data. If
the data is being served from a squid cache rather than from a cache on
the wiki server, how will this reduce the overall I/O blocking problem?
The busiest page data won't substantially add to I/O blocking on the
wiki server as it will likely be in memory all the time. The squid proxy
  is ideal to solve the problem of network load from commonly accessed
pages or pages which demand a lot of CPU power to generate but this is
not a problem on wikipedia. If Squid proxies are being implemented to
increase performance, then they are the right solution to the wrong
problem. If they are to increase reliability by adding redundancy -
multiple data sources-, they do this to a degree but are far from ideal.

The most commonly used pages are going to be in the memory of the
database server so these are not costly to serve. The costly pages to
serve are those which need disk seeks to serve. The more I/O seek
operations a page requires, the more costly it is to serve.

The proxy server will need to make a database lookup (for the URL) and,
unless the page is in memory rather than on-disk storage, use I/O to
reach the fine grained data. The data for each unique URL will be bigger
than that held in cache on the database server as it will contain html
formatting and other page data. The likelihood of the data being in the
memory of a proxy server is lower than the data being in memory of a
similarly equipped database server as the data size of the final HTML
page will be ~7.5k bigger than that of the database data.

If performance is the criteria, I suggest a proxy isn't a good idea.
Instead, the memory otherwise used in a proxy would be better utilised
caching database data directly. Either as a ramdisk or perhaps a network
attached database storage with plenty of solid statememory.

 From what I have gathered, the cost (limiting factor to performance) is
that of delays seeking fine grained data. Either this seek load will
need to be spread across many mechanical devices such that the work is
not unduly duplicated, or store the fine grained data in solid state
storage so that it can be seeked quickly.


from_name: Daniel Mayer

subject: [WikiEN-l] Re: Audience : was Re: pictures of genetalia

body:
Anthere wrote:
>I am a representant of your french audience.
>You could write for me.

No I can't, since I don't speak French. But since you speak and read English
you *are* part of the audience I write for when I write in English (just not
the primary one).

>I guess we will have both to see that we are not
>writing for the same audience. As long as you
>accept that some do not recognise these notions
>of *primary* and *secondary* as valid, while others
>do, that is fine.

This whole discussion was more academic than practical since things naturally
develop toward what I described unless unnatural force is applied to direct
things down another path (which does happen for individual articles but on
the whole it is not a very significant force).

Those of us who speak more than one language, however, should remember that
there are different notions of how to organize information in different
languages. They should therefore not just assume that the way they do things
in their primary language is necessarily transferable in other languages they
may know.

This is one thing that I have learned while working on Wikipedia.

-- Daniel Mayer (aka mav)


from_name: Peter Bartlett

subject: [WikiEN-l] My view on deletions

body:
>-----Original Message-----
>From: wikien-l-bounces at Wikipedia.org
[mailto:wikien-l-bounces at Wikipedia.org] On Behalf Of Jimmy Wales
>Sent: 12 January 2004 20:27
>To: wikien-l at wikipedia.org
>Subject: [WikiEN-l] My view on deletions
>
>
>At least one person has privately expressed to me the opinion that my
position on deletions is that nothing should be deleted.  That's
absolutely not
>true, and I thought that this misunderstanding might be widely enough
shared that I should speak to it for a moment.
>
>I think that the vast majority of deletions are perfectly fine.
Deletions for vandalism seem to be pretty well not abused.  Borderline
cases, with a
>fairly open policy, are sent to VfD now, and that almost always works
out just fine.
>
>But I'm unhappy with some deletions (and redirections) that happen on
VfD.  I call the process broken by analogy with hypothetical (and
virtually all
> real!) criminal justice systems that get the right answer most of the
time, but for various procedural reasons sometimes do exactly the wrong
thing.
>
>But in no way am I saying anything even remotely supportive of the idea
that vandals should be given free hand, nor that deletion or redirection
should
>always be avoided at all costs.  They are important tools, but we need
to improve how we use them.

In my experience mistakes occur much more frequently over "instant
deletion" pages rather than the VfD page. It's not a coincidence that
VfD decisions are made collectively and instant delete are made
individually. VfD mistakes are so few and far between (I think only the
Palestinian views... article has been cited in this discussion as a VfD
mistake and that is only debatably a mistake - given all our policies on
page-naming) that it is probably not worth your worrying about too much.
Instant deletion mistakes (in the sense that the page should've gone to
VfD or even cleanup rather than instantly deleted) are made on a (I
estimate) daily basis. A timely reminder to work the VfD process rather
than bypassing it by insta-deleting may be in order.

Pete/Pcb21


from_name: Dave Caroline

subject: [Wikitech-l] Re: Secondary servers and the final solution

body:
At 00:07 13/01/2004 +0000, you wrote:
>Gabriel Wicke wrote:
>
>>How about installing Squid on one of the machines? That would take a fair
>>amount of load away. Is there a machine with some free Ram available?
>>Even installing Squid on larousse would do i guess. I've glanced over the
>>php code- there are mainly two header lines we would need to change to
>>activate this- we could start off with a 30 minute timeout for anonymous
>>users. Purging should get ready soon as well.
>
>Perhaps I will be burned at the stake as a heretic for this, but I am not
>convinced squid proxies are the answer.

You should not be burnt

>The delays in the wikiserver system are caused by waiting for I/O- the
>time taken for mechanical devices to seek a particular block of data. If
>the data is being served from a squid cache rather than from a cache on
>the wiki server, how will this reduce the overall I/O blocking problem?

Agreed

>The busiest page data won't substantially add to I/O blocking on the wiki
>server as it will likely be in memory all the time. The squid proxy  is
>ideal to solve the problem of network load from commonly accessed pages or
>pages which demand a lot of CPU power to generate but this is not a
>problem on wikipedia. If Squid proxies are being implemented to increase
>performance, then they are the right solution to the wrong problem. If
>they are to increase reliability by adding redundancy - multiple data
>sources-, they do this to a degree but are far from ideal.
>
>The most commonly used pages are going to be in the memory of the database
>server so these are not costly to serve. The costly pages to serve are
>those which need disk seeks to serve. The more I/O seek operations a page
>requires, the more costly it is to serve.
>
>The proxy server will need to make a database lookup (for the URL) and,
>unless the page is in memory rather than on-disk storage, use I/O to reach
>the fine grained data. The data for each unique URL will be bigger than
>that held in cache on the database server as it will contain html
>formatting and other page data. The likelihood of the data being in the
>memory of a proxy server is lower than the data being in memory of a
>similarly equipped database server as the data size of the final HTML page
>will be ~7.5k bigger than that of the database data.

One solution is to lower the options available to the user to make the
pages more static (unpopular)

>If performance is the criteria, I suggest a proxy isn't a good idea.
>Instead, the memory otherwise used in a proxy would be better utilised
>caching database data directly. Either as a ramdisk or perhaps a network
>attached database storage with plenty of solid statememory.

Probably the only solution apart from splitting the various wikis to more
servers

> From what I have gathered, the cost (limiting factor to performance) is
> that of delays seeking fine grained data. Either this seek load will need
> to be spread across many mechanical devices such that the work is not
> unduly duplicated, or store the fine grained data in solid state storage
> so that it can be seeked quickly.
>

Or data replication over more/many db servers.

We really do need to spread the load (high power processors are less
important than high speed disk.

As things are at the moment to cache the db to get full performance we need
a server with 50gig ram (we cannot get 4gig working yet).

So for the next best thing I believe the suggested hot swap disk array is
needed for both performance and reliability (2 off) to make two fast db
servers.

plus squids apaches and dns round robin etc

Dave Caroline aka archivist


subject: [Wikitech-l] Re: Re: Secondary servers

body:
On Tue, 13 Jan 2004 00:07:50 +0000, Nick Hill wrote:

> Gabriel Wicke wrote:
>

>
> The delays in the wikiserver system are caused by waiting for I/O- the
> time taken for mechanical devices to seek a particular block of data. If
> the data is being served from a squid cache rather than from a cache on
> the wiki server, how will this reduce the overall I/O blocking problem?

If we have an old machine Squid will serve anything cached straight from
memory (small objects) or disk (images) without ever contacting the
database. That's a speedup of at least 50x over the current disk cache
with DB lookup etc. The bigger the Ram for the Squid the better of course,
but 500Mb will already hold a lot of compressed html.

> The most commonly used pages are going to be in the memory of the
> database server so these are not costly to serve. The costly pages to
> serve are those which need disk seeks to serve. The more I/O seek
> operations a page requires, the more costly it is to serve.

Yup. So lets avoid them.

>
> The proxy server will need to make a database lookup (for the URL)

Nope. Only if a page is *not* in the cache or marked as not cacheable.

> If performance is the criteria, I suggest a proxy isn't a good idea.

Well- please read up some docs. Or benchmark http://www.aulinx.de/ -
commodity server (Celeron 2Ghz) running Squid.

--
Gabriel Wicke


subject: [Wikitech-l] Re: Re: Secondary servers

body:
Gabriel Wicke wrote:
> On Tue, 13 Jan 2004 00:07:50 +0000, Nick Hill wrote:

>>The most commonly used pages are going to be in the memory of the
>>database server so these are not costly to serve. The costly pages to
>>serve are those which need disk seeks to serve. The more I/O seek
>>operations a page requires, the more costly it is to serve.
>
>
> Yup. So lets avoid them.

Given that popular articles will be in the database memory cache,
requests for popular articles should not lead to database HDD seeking.

I would expect a Squid proxy be best at serving popular pages and poor
at serving less popular pages. So I can't imagine how squid is very
helpful at saving HDD seeks.

>>The proxy server will need to make a database lookup (for the URL)
>
>
> Nope. Only if a page is *not* in the cache or marked as not cacheable.
I meant the squid server will need to look up it's own database (in
whatever form that may be- filesystem or indexed DBMS) to check if it
has a copy of the required data- using the URL as a key. If it has a
copy of the data, it will need to either pull it out of memory or from
the disk. If not, forward the request then add the page to it's own
database.

If the squid server needs to pull an article page off the disk, then
disk I/O will be required in the same way as it would be required if an
uncached piece of data is read from the database by the web server.

As I/O is the bottleneck, the squid server is likely to suffer the same
problems as the underlying database server. These problems are likely to
be bigger as the chunks of fine grained data handled by squid will be
larger (compressed fully formed HTML pages) than the fine grained chunks
of data (article text) handled by the database server.

>>If performance is the criteria, I suggest a proxy isn't a good idea.
>
>
> Well- please read up some docs. Or benchmark http://www.aulinx.de/ -
> commodity server (Celeron 2Ghz) running Squid.

I am not contending that squid is not a very high performance server. I
believe it is a high performance server. I believe it can substantially
reduce the bandwidth needed by ISPs to serve web surfers.

The issue for wikipedia is how many disk accesses, in total, are needed
for each article hit.

Wikipedia has millions of discrete pieces of data. Most pieces
referenced singularly by a unique URL. Squid will not be able to hold a
substantial proportion of these in memory. Squid will be able to hold
fewer of these data chunks (articles/ HTML pages) in a given amount of
memory than a database server could as the articles stored on the
database consist of less data than the article rendered in HTML. For the
larger articles, the comressed html page will be smaller, but for most
articles, the compressed HTML page will be bigger. (the relative weight
of the page HTML is much greater for short articles than for long
articles. Compression reduces page size by about half.)

I assume viewing an article history page requires several pieces of
information leading to multiple seeks per request: If squid were able to
serve article histories, then a single I/O on the squid box could save
several database seeks on the database server, providing a substantial
economy. However, individual page histories are each fairly rare and
forcing a squid cache reload on an article history page when an article
is updated may be a poor use of resources.

I suggest four avenues for investigation:
1) Store articles in the MySQL table in compressed (gzip) format. This
will reduce the size of the articles, making them fit more easily into
the available cache memory, increasing the chances of a cache hit almost
by a factor of two. Perhaps this can be made as a patch to MySQL.
2) Investigate ways of prioritising data cached in memory such that
smaller chunks of data have a higher value than larger chunks so that
smaller chunks are not flushed according to the basic least recently
used algorithm. To reflect the relative cost of reading a small chunk of
data from the HDD.
3) If the SQL code underlying wikipedia relies on temporary tables as
part of the SQL queries, investigate whether the I/O of writing
temporary tables tends to flush data from the disk cache. If so, write
temporary tables to ramdisk or other storage which does not cause
flushing. More recent versions of MySQL support sub-queries. This may
obviate the need for temporary tables.
4) Judicious use of solid state storage. Could dramatically reduce seek
times and I/O bottleneck. Some issues to resolve regarding flash memory
durability and possible MySQL hotspots. Also cost of mass solid state
storage. Might be worthwhile for some wiki data.


subject: [Wikitech-l] Re: Re: Secondary servers

body:
On Mon, 12 Jan 2004 16:23:30 -0800, Brion Vibber wrote:

> The ideas about squid caches etc are not about lightening the load on
> the database server

Ahem.

> (which it wouldn't really do except insofar as it
> may cache more stuff than our present on-web-server caching), but about
> lightening and spreading out the load on the web servers. Squid caches
> will *not* help the immediate question here to a significant degree;
> anyway no more than making slight alterations to the present caching
> code to avoid checking timestamps in some cases would.
>
> Our present alternatives for database duty are:
>
> * Pliny, which has done it in the past. Exhibiting intermittent errors
> on primary drive, and crashed a couple times when it ran the database
> again in late December, which is why we took it back off to Ursula.
>
> * Carol (currently idle) with a SCSI drive that's too small for the
> whole database.

Doesn't matter, that's what a replacement algo is for. There are much more
sophisticated ones than LRU to pick from- both for ram and for disk.

> * Susan (currently idle) with another IDE drive that's likely not the
> fastest.

If these two servers have some Ram they'll be fine. We could even disallow
disk caching all together, only using their Ram.

--
Gabriel Wicke


subject: [Wikitech-l] Secondary servers

body:
Nick Reinking wrote:

> I'm not sure how running two copies of MySQL on a machine is going to be
> faster than running one.  Plus,
> I don't think MySQL can even work in this configuration.

I am not saying running two copies per se will be faster. Just that
running a copy from a database file in ramdisk will be much faster. One
instance of Mysql whose data file is on the mechanical disk, one
instance being a replication slave whose data is on the ram disk. Data
served from the ram disk, not the hard disk.

I am almost certain multiple instances of MySQL will co-exist on the
same machine. If not directly, then through a chrooted environment.
Sockets can span chrooted environments using 'mount --bind'.


subject: [Wikitech-l] Re: Re: Re: Secondary servers

body:
On Mon, 12 Jan 2004 17:15:38 -0800, Brion Vibber wrote:

> Squid may be a great caching system, but for purposes of this
> discussion it's not really different from what we've got.

Believe me that Squid is *way* faster than any php caching system will
ever be- with modification date checking or not. Especially at serving
whatever fits into ram. Please benchmark http://www.aulinx.de/. I did from
localhost- Squid is serving more than 700 requests per second at 55% Cpu
with 46% taken up by siege. en2.wikipedia did about 8 Requests per second
when i checked. Deatails at http://www.aulinx.de/oss/code/wikipedia/,
about 1/3 down.

If you don't want to know or check- then fine. I'm just offering help.

--
Gabriel Wicke


subject: [Wikitech-l] Re: Re: Re: Re: Secondary servers

body:
On Mon, 12 Jan 2004 18:06:43 -0800, Brion Vibber wrote:

> This thread is about disk access on the temporary database server.
>
> No matter how insanely fast the caching is, it doesn't happen on the
> database server. Superduperfast squid caching that doesn't touch the
> database server and kinda speedy php caching that doesn't touch the
> database server are exactly equal in the eyes of the database server.

Sorry- i misunderstood you then (i admit to have only crossread the
thread). But still the latter doesn't provide a timeout and is slower
overall. Switching off time checking is really quick to do of course, so
why not.

I'll try to do the purge script tomorrow, then we could use the idle
machines as static caches without timeout (and switch the modification
time check on again).
--
Gabriel Wicke


from_name: Nikos-Optim

body:
Can I have clarifications on:

1. If native English speakers is "primary" audience
while the non native speakers is "secondary", does
that mean for you that an article on the next USA
elections is OK, while an article on the next
elections of Egypt (put here any other country) are
irrelevant and of no interest to English Wikipedia's
audience?

2. Or that a terrorist attack in USA should be more
important than a terrorist attack in Nepal, if both
attacks have the same number of killed or injured
people?

Thank you,
--Optim

--- Anthere <anthere8 at yahoo.com> wrote:
>
>
> Daniel Mayer a ?crit:
> > Anthere wrote:
>
> >>If english people write only or mostly for english
> people,
> >>if french people write only or mostly for french
> people, if
> >>arab people write only or mostly for arab people,
> then we
> >>fail. Wikipedia fails.
> >
> >
> > OK, that has got to be the most bizarre thing I've
> read in a while.
>  > I write
> > for *all* English speaking people. Sorry but how
> can I write for a French
> > audience when I don't speak French?
>
> I am a representant of your french audience. You
> could write for me.
>
> I guess we will have both to see that we are not
> writing for the same
> audience. As long as you accept that some do not
> recognise these notions
> of *primary* and *secondary* as valid, while others
> do, that is fine.
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus


subject: [WikiEN-l] Reading Software

body:
> There even is no need for any special hidden
> punctuation: it should not be a
> problem for the software to automatically add a ; at
> the end of every heading
> and list item.

you mean Wikipedia's software (for the "Speakable
Version" link), right?

--Optim

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus


body:
The WikiMoney plan was mostly humourous, as I said:
"dont take it very seriously".

I agree to list pages first on Cleanup and then to
VfD. For how much time would list the pages on
Cleanup? I suggest to open a poll and let the
community to vote on it. My vote is "same as VfD lag
time", i.e. 5 days. But I don't really have any
problem with the "2 weeks" suggestion.

--Optim

--- Dan Miller <meelar2 at yahoo.com> wrote:
> For those who haven't been following the discussion
> on
> Talk: Votes for Deletion, I thought I'd drag this
> idea
> into the light of debate:
>
> I agree that the VfD process is overused; look at
> the
> relatively high proportion of "keep" votes. Ideally,
> only pages that are relatively clear-cut cases would
> go here, with the rest being moved to cleanup or
> elsewhere. But the WikiMoney plan would harm new
> users, and also be quite complicated to use. Why not
> a
> better plan, such as:
>
> Before any page can be listed on regular VfD, it
> must
> be listed on cleanup and left there for some time;
> I'm
> thinking two weeks, but this is negotiable. After
> that, it can be moved to VfD, and a vote can be
> held.
> Of course, the regular candidates for speedy
> deletion
> could go, and the copyvio delete page would be
> unaffected. Not only would this solve the overuse of
> VfD, it would also help stop the occasional listing
> on
> VfD of copyvios. And, it could be accomplished by
> simply placing a notice at the top of the VfD page,
> rather than encumbering everyone with a complicated
> system of WikiMoney, which might frighten newbies
> and
> irritate old hands.
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus"
> Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus


from_name: Jimmy Wales

subject: [Wikitech-l] Secondary servers

body:
Nick Hill wrote:
> >I'm not sure how running two copies of MySQL on a machine is going to be
> >faster than running one.  Plus,
> >I don't think MySQL can even work in this configuration.
>
> I am not saying running two copies per se will be faster. Just that
> running a copy from a database file in ramdisk will be much faster. One
> instance of Mysql whose data file is on the mechanical disk, one
> instance being a replication slave whose data is on the ram disk. Data
> served from the ram disk, not the hard disk.

I think others have said this, but I think you're behind the times
when you talk about a "ramdisk".  We're not running DOS here.  Linux
will already cache as much as it can in memory, and in a sensible and
automatic way.

But realistically speaking, this is not a bottleneck worth trying to
solve.  When it's working, the db server is very fast, and already
holds everything that it needs in memory, as far as I know.

--Jimbo


body:
Dave Caroline wrote:
> >The delays in the wikiserver system are caused by waiting for I/O- the
> >time taken for mechanical devices to seek a particular block of data. If
> >the data is being served from a squid cache rather than from a cache on
> >the wiki server, how will this reduce the overall I/O blocking problem?
>
> Agreed

I think you're both wrong about this.  This is not where the
bottleneck is, when Geoffrin is running.  It *is* where the bottleneck
is right now, because we're limping along on broken hardware.

--Jimbo


subject: [Wikitech-l] Secondary servers

body:
Nick Hill wrote:
> I understood the server was I/O bound from a recent posting. Server
> maxed out with low CPU utilisation. The information you and I have
> differs. You are in a position to have better information on this than
> I. I certainly don't want to waste time solving a non-existent problem.

Yes, well, you weren't completely misinformed, but just missed one
crucial detail.  :-) We are currently I/O bound on the db server
because the one that we're using sucks.  It's what we are limping by
on until the new hardware is installed, or until I manage to find
something for Brion to put into service.

> Do we have a bottleneck? If so, where is it and how do we know?

Bigger picture, I think that the configuration that we've discussed is
the right way to go, and no exotic hardware configurations are needed
to serve the website quickly, effectively, and reliably.

squids->webservers->db servers

with auxiliary servers for other jobs.

I'm putting the finishing touches on an order at Silicon Mechanics
right now, and I'll report back to everyone once I have all the
details and a firm delivery date promise.

--Jimbo


from_name: Anthere

body:
Daniel Mayer a ?crit:
> Anthere wrote:

>>If english people write only or mostly for english people,
>>if french people write only or mostly for french people, if
>>arab people write only or mostly for arab people, then we
>>fail. Wikipedia fails.
>
>
> OK, that has got to be the most bizarre thing I've read in a while.
 > I write
> for *all* English speaking people. Sorry but how can I write for a French
> audience when I don't speak French?

I am a representant of your french audience. You could write for me.

I guess we will have both to see that we are not writing for the same
audience. As long as you accept that some do not recognise these notions
of *primary* and *secondary* as valid, while others do, that is fine.


from_name: Dan Wahl

subject: [WikiEN-l] linked to page

body:
Dear wonderful wiki,

Some of the community may be interested in these links, from my
page --
http://mavweb.mnsu.edu/wahld1/Dan/gender_neutral_essay.htm#_f
tn2

to these pages --
www.wikipedia.org/wiki/Singular_they
http://en.wikipedia.org/wiki/Sie_and_hir

Thank you,

Dan Wahl

---


subject: [WikiEN-l] Reading Software

body:
yes I like this idea on plain text

--- Gutza <gutza at moongate.ro> wrote:
> Nikos-Optim wrote:
>
> >>There even is no need for any special hidden
> >>punctuation: it should not be a
> >>problem for the software to automatically add a ;
> at
> >>the end of every heading
> >>and list item.
> >>
> >>
> >
> >you mean Wikipedia's software (for the "Speakable
> >Version" link), right?
> >
> >--Optim
> >
> >
> Yes, that's the idea, tweaking the Wiki's
> "rendering" engine as to
> produce proper "markup" for reading, as opposed to
> the two existing
> variants or markup (regular and print).
>
> I also proposed a "simple" rendering version some
> time ago IIRC, don't
> remember what came out of that. My idea was to be
> able to access the
> articles as plain text -- no links, no images, no
> markup, no nothing,
> just plain (maybe flowed, as in the MIME type?) text
> with proper spacing
> (one empty line between paragraphs, bullets
> represented as asterisks and
> indented lists, etc). That could be used for various
> purposes, for
> instance it would make it really easy to integrate
> in third-party online
> applications, such as multiplayer games (just one
> example that came to
> mind).
>
> --Gutza
>
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus


subject: [WikiEN-l] Wall Street Journal article about Wikipedia

body:
I recently requested permission to copy some very
interesting articles from a major Greek translation
vortal (portal) into Wikipedia and Wikisource, asking
for info on their copyright status too.

during our discussion about the copyright, the owner
of the website told me that he uses Wikipedia very
often and he likes it.

--Optim

--- "Poor, Edmund W" <Edmund.W.Poor at abc.com> wrote:
> The Wall Street Journal mentioned Wikipedia.org in
> yesterdays Business
> Solutions column (by Michael Totty):
>
> >> A wiki page looks like any Web page, but with a
> difference: With
> >> the click of a button, a visitor can add new
> material to the page
> >> or change what's already there. Others can see it
> once they
> >> refresh the page. This isn't as disruptive as it
> sounds; all
> >> changes are tracked, and earlier versions can be
> restored if
> >> important information is deleted. There is even a
> wiki
> >> encyclopedia (Wikipedia.org), where anyone can
> add or amend
> >> entries.
> >>    -- Wall Street Journal, Monday, January 12,
> 2004 Page R4
>
> Ed Poor, aka Uncle Ed
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus


subject: [WikiEN-l] User:Annek

body:
In general, I would call that bannable behavior, but you don't seem so
upset about it, since it seems like it might just be a single isolated
incident.  It's totally unacceptable, but if it doesn't happen again.

Of course, Annek has just destroyed all credibility for himself, so...

Tucci wrote:

> As far as I can remember, I have never interacted with
> User:Annek in any way.  Looking at his contributions,
> it's possible I changed something he didn't like,
> since he's edited [[hip hop]] and some other articles
> I watch.  There's never been any conflict between us,
> however.  He has changed a sentence describing me on
> my own userpage from "I am also homosexual" to "I am a
> fag".  I don't appreciate it, for perhaps obvious
> reasons, and have let him know on his talk page.  I
> don't know what, if anything, we want to do about
> this, especially if it remains a single isolated
> incident, but I wanted to bring it up to the mailing
> list.
>
> TUF-KAT
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Nikola Smolenski

subject: [WikiEN-l] Reading Software

body:
On Tuesday 13 January 2004 04:33, Peter Jaros wrote:
> On Jan 12, 2004, at 8:28 PM, Nikos-Optim wrote:
> > I would like to find some way to
> > incorporate some hidden punctuation into the articles,
> > which will be used only by reading software but will
> > be invisible to the user who reads the text on the
> > screen or paper. Do you have any idea on this?
>
> Easiest way is probably to have an equivalent to the "Printable
> Version" link.  Users load the "Speakable Version", complete with
> punctuation marked-up as hidden, and feed it to the reading software.
> Voil?!

There even is no need for any special hidden punctuation: it should not be a
problem for the software to automatically add a ; at the end of every heading
and list item.


from_name: Poor, Edmund W

body:
The Wall Street Journal mentioned Wikipedia.org in yesterdays Business
Solutions column (by Michael Totty):

>> A wiki page looks like any Web page, but with a difference: With
>> the click of a button, a visitor can add new material to the page
>> or change what's already there. Others can see it once they
>> refresh the page. This isn't as disruptive as it sounds; all
>> changes are tracked, and earlier versions can be restored if
>> important information is deleted. There is even a wiki
>> encyclopedia (Wikipedia.org), where anyone can add or amend
>> entries.
>>    -- Wall Street Journal, Monday, January 12, 2004 Page R4

Ed Poor, aka Uncle Ed


subject: [WikiEN-l] User:Annek

body:
This is a sensitive human relations issue. It's difficult for
many people to restrain their hostility towards others who have
different moral or political values. We here, however, have made
a working agreement that we will not make personal remarks.

I openly declared myself a member of the Unification Church, a
group which is highly offensive to many people. But I've made it
known that I don't like being called a "Moonie" or a "cult
member", and with few exceptions other contributors have
respected my request.

We /must/ follow the guideline of avoiding personal remarks, or
the process which has brought us so much success will break
down. The place to describe points of view about moral or
political topics is in the articles, and the /way/ to describe
these POVs is Jimbo and Larry's "neutrality doctrine" (see
[[Wikipedia:NPOV]]).

I will talk to user:Annek.

Ed Poor, aka Uncle Ed


subject: [WikiEN-l] An end to ugliness (was: This is getting ugly)

body:
Peter Jaros wisely observed:

> That said, there *is* a substantive issue hidden in this mess.  The
> NPOV of certain articles is being questioned.  Let's address that.
> What has happened to the articles in the past does not matter anymore.

> Remember, the page history may exist, but it's the latest revision
that
> counts.  Let's discuss what *is* there and what *should be* there.
> Without accusing each other of anti-Anythingism.

Behind all the personal remarks probably lurks unexpressed or unresolved
feelings about values. It's often easier to castigate a person, than to
articulate one's values. Especially quickly. And even more so when
constrained by the Neutral Point of View. "Neutral? Screw neutral, I'm
going to kill those bastards!"

But our only business here is to craft neutral articles, even on life
and death issues. We either work together, or we leave the project.

That's why I often recommend we cool off. Take a weekend, a month, and
don't write about controversial stuff if you can't keep your temper in
check. I follow my own advice.

Ed Poor, aka Uncle Ed


subject: [WikiEN-l] User:Annek

body:
Personal remarks like the following are out of place in this project:

* you ... imbecile

It would be better to say something like:

* Can't you see that X is Y; or,
* Here is a reference which explains the matter differently.

I will talk to user:LizarkKing

Ed Poor, aka Uncle Ed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20040113/396b1df7/attachment.htm


from_name: Vicki Rosenzweig

body:
At 04:23 AM 1/13/04 -0800, Optim wrote:
>Can I have clarifications on:
>
>1. If native English speakers is "primary" audience
>while the non native speakers is "secondary", does
>that mean for you that an article on the next USA
>elections is OK, while an article on the next
>elections of Egypt (put here any other country) are
>irrelevant and of no interest to English Wikipedia's
>audience?

No. It does mean that more background might be needed
for an article on elections in a non-English-speaking country,
since the readers would almost certainly be foreign to that
country.

>2. Or that a terrorist attack in USA should be more
>important than a terrorist attack in Nepal, if both
>attacks have the same number of killed or injured
>people?

Of course not.


from_name: Nick Reinking

subject: [Wikitech-l] Re: Secondary servers

body:
On Tue, Jan 13, 2004 at 03:06:29PM +0100, Gabriel Wicke wrote:
> On Tue, 13 Jan 2004 05:46:15 -0800, Jimmy Wales wrote:
>
>
> > I'm putting the finishing touches on an order at Silicon Mechanics right
> > now, and I'll report back to everyone once I have all the details and a
> > firm delivery date promise.
>
> Jimbo-
>
> how much ram are you going to order for the Squids? I've read that it's
> possible to address more than 4Gigs though highmem on x86, but only 3
> Gigs per process. Squid is a single-thread asynchronous app, so this is a
> limit. Is there a major price penalty in a single-processor 64bit CPU?
> Having enough ram for all content on the Squids is a good thing for both
> speed and reliability- not an immediate problem for now, but it might get
> one as wikipedia grows. On the other hand x86 Squids could be converted to
> Apaches later if they are the same kind of machine.
>
> The ram issue propably also applies to the DB server, but i guess you'll
> order 64bit anyway for that.

I would hazard a guess that 1GB, maybe 2GB is all that should be needed.
That should provide plenty of RAM for disk caching.  Linux and Squid are
pretty good about that.  No need to spend a lot of money on 64-bit
machines for the Squid servers.

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


body:
Viajero wrote:

> Adam Carr demonstrated on articles like [[Anti-zionism]] that it
> seems to make a huge difference if ONE individual takes charge of
> the article with no particular authority except the confidence of
> other contributors. Adam is by no means impartial (who is?) but he
> has a gift for synthesizing various POVs into an effective, well-
> written organic whole.

I think this will work for any topic, provided an individual can be
found who can win the confidence of the other contributors. I myself
have managed to gain a degree of trust at [[Silesia]], and I have
hopes that it may be sufficient to enable me to do in the Balkans
what Viajeron suggests for the Middle East.

Ed Poor, aka Uncle Ed


subject: [Wikitech-l] The order

body:
8 SM-1151SATA, P4 2.6, 2x1GB RAM, 80GB SATA RD, Redhat 9 preload,
1.44Mb floppy, rail kits.

The 2x1Gb was more expensive than 4x512Mb, but gives us more
flexibility for growth and also for shuffling the memory around to
specialize the machines.  For machines that aren't doing anything too
intensive (mail server), we can buy cheap 2x256=512Mb and donate the
extra 2gb to the squid(s), if that seems helpful.  And there will be
slots available to just buy more memory outright if that seems like a
good idea.

8 machines gives us some oomph, no matter what.

1 SM-2280S, Dual AMD Opteron 246, 4GB memory, SCSI RAID 5, 3x36,
logical capacity 72GB, redundant power supply, RH9 preload, 1.44mB
floppy,, rail kits.

This machine is very similar to our big dog geoffrin.

The total cost is $19,308, plus tax and shipping.

--Jimbo


subject: [Wikitech-l] Access patterns, disks, etc.

body:
On Tue, Jan 13, 2004 at 03:31:29PM +0000, Neil Harris wrote:
> == Not all disks are equal ==
>
> Consider buying the disks specifically by access time statistics. In
> particular, high-performance SCSI disks should greatly out-perform IDE
> for random seek access patterns, even though their performance may be
> roughly the same for data streaming. SCSI command tagging will further
> increase performance, where there is concurrency on a single spindle.
>
> See http://www.storagereview.com/php/benchmark/bench_sort.php for some
> interesting stats:
>
> *  a Fujitsu MAS3735 has an average read access time of 5.6ms, for a
> price of $700 for 73 GB.
> * a Hitachi Deskstar 7K250 has an average read access time of 12.1ms,
> for a price of $250 for 250 GB
> * a seagate U6 has an average read access time of 20.0ms, for a price of
> ??? for 80 GB

Also, it should be noted that if we want to extend the usefulness of
current machines, there are some 10K Western Digital IDE drives
(basically SCSI drives with an IDE interface).  They have an average read
access time of 8.3ms (the WD740GD does, at least), and is $260 from
Newegg for the same size (74GB).  It also has a built-in PATA-to-SATA
bridge, so it supports hot-swapping and command queueing.

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


body:
Optim wrote:
>1. If native English speakers is "primary" audience
>while the non native speakers is "secondary", does
>that mean for you that an article on the next USA
>elections is OK, while an article on the next
>elections of Egypt (put here any other country) are
>irrelevant and of no interest to English Wikipedia's
>audience?

All info is OK to have. I was just talking about its organization. Please read
what I said again.

--mav


subject: [WikiEN-l] Audience : was Re: pictures of genetalia

body:
Tarquin wrote:
>In terms of material and content, we should consider
>the audience of all wikipedia languages to be international.
>(Naturally, in terms of the vocabulary and grammar, we
>write for competent speakers of the language.)

Yes - of course. But I would add that what passes for an an encyclopedia
article in one language - how it is organized and split up - is not
necessarily going to be the same between two languages. Even what is included
in an encyclopedia vs other works of reference is going to differ between
different languages. Some languages have a tradition of having many articles
on words, while others have a tradition of segregating articles on words into
more minimal entries in dictionaries.

-- Daniel Mayer (aka mav)


subject: [WikiEN-l] Shades of Rashomon

body:
Viajero wrote:

> Several of us were discussing the topic on the IRC channel in
> December (Anthere may remember this because she was one of
> them) and this question came up. One person said they thought
> WP (EN) had a pro-Israeli bias. Another said a pro-Palestinian
> bias. A third said neither POV was accurately represented.

I haven't seen Rashomon, but I understand the reference:
three or more people saw the same event and give widely
divergent accounts of it. I think this cuts to the core
of the difficulty in describing Middle East history and
current events.

Who among us can see without using a mental filter? I do
not claim this ability. Despite my high estimate of my
own objectivity, I am uncomfortably aware that from time
to time I am simply WRONG.

I daresay portions of articles are indeed tinged (or
infected) with pro-Israeli or pro-Palestinian bias. We
might never eliminate either of these biases entirely.
But we can work at it.

The key is identification: if it smells, change it.
Refactor the article so that it says the same thing but
/attributes/ POV to its proponent. I don't know why this
is so hard, but (A) it really is hard and (B) it really
is important.

Let's do it.

Ed Poor, aka Uncle Ed


body:
Erik wrote:
>The English Wikipedia should be orientated toward the English
>*language*.

Exactly my point. The English language has its own traditions on how to
organize information - that does not mean, however, that we exclude
information or not follow NPOV.

>I don't think it should be orientated toward the English-speaking
>*culture*, if there even is such a thing. That would be inherently
>POV.

I agree.

-- Daniel Mayer (aka mav)


subject: [Wikitech-l] ETA on the order

body:
Build in approximately 5 business days, and then shipping will take
approximately 5 more business days.

So that's two weeks in dog years, give or take.  Let's say January
27th.


subject: [WikiEN-l] Re: Audience

body:
Anthere wrote:
>I agree. That is why we do need to present the penis with
>which a baby born and grew up, if not modified, as a "penis".
>Not as an "uncircumsed penis".

Uh, no. If and when the article [[penis]] gets large enough, then it will make
sense to have more photos. One of those photos will be one of an circumcised
penis. Given that circumcision is relatively common among English readers
(our audience) we can expect to have - naturally - a relatively large section
at [[penis]] about circumcision.

I'm sure that in languages other than English in which circumcision is much
rarer, that there may never be a whole section in their [[penis]] article
about that - just a sentence or two and a link in their section dealing with
all penis modifications.

Having more than that may bore an audience where circumcision is not as common
- that sub-topic isn't really as relevant to the the subject for them as it
would be to readers for whom circumcision is more common. So just because it
makes sense to you as a non-native speaker that a photo of a circumcised
penis is not really very relevant to the penis article, please do not think
that that would make sense to a native speaker.

Relevance is a relative thing. So know your audience and select information
that is most useful to them and organize it accordingly. That is going to be
different in different languages (even when NPOV is followed faithfully). But
again this happens naturally on Wikipedia due to the fact that the different
language versions give each language the opportunity to develop articles that
are most useful to their readers.

-- mav


from_name: Ray Saintonge

body:
Nikos-Optim wrote:

>The WikiMoney plan was mostly humourous, as I said:
>"dont take it very seriously".
>
Regretably, when things are said tongue-in-cheek, some readers see the
tongue as being in the wrong set of cheeks. :-)

>I agree to list pages first on Cleanup and then to
>VfD. For how much time would list the pages on
>Cleanup? I suggest to open a poll and let the
>community to vote on it. My vote is "same as VfD lag
>time", i.e. 5 days. But I don't really have any
>problem with the "2 weeks" suggestion.
>
Where's the urgency for such short periods.  People will work on these
things when they have the time.  A simple note at the top of the page
will often be a sufficient warning about the nature of the problem.
 Rule makers sometimes forget that even if the problem article falls
within a person's sphere of interest, the most valuable contributors are
often busy with articles or projects of their own; they should feel no
need to drop everything to take the time to properly research something
that another person considers inadequate.

Periodically recycling the Cleanup list through people's attention could
be more productive than pressure tactics.

Ec


from_name: Tucci

subject: [WikiEN-l] User:Annek

body:
--- Jimmy Wales <jwales at bomis.com> wrote:
> In general, I would call that bannable behavior, but
> you don't seem so
> upset about it, since it seems like it might just be
> a single isolated
> incident.  It's totally unacceptable, but if it
> doesn't happen again.
>
> Of course, Annek has just destroyed all credibility
> for himself, so...

Ordinarily, the word doesn't upset me.  My (mostly
straight) friends and I lob all manner of racial and
sexual slurs towards each other at every available
opportunity, but since Annek didn't know that I can
only assume he meant it as a dire insult.  I agree
that, as long as it is a single incident, there's no
call for banning (Annek isn't very active anyway) but
I am now seriously considering the possibility that he
and Lizard King are the same person.  Aside from both
launching sexual slurs at me on the same day (in
Annek's case, with no apparent provocation) is
suspicious, as is Lizard King's comments at his talk
page and Talk:Bigfoot, where he seems to know more
about what is going on and what will be done to check
his identity than a new user should know.  He dared me
to check the IP address for him and Annek, and I'm
certain they will be different, just as he claims...
Regardless, I will be monitoring Annek.

For the record, anyone following the Lizard King
debacle, all of my interaction with him has been on
Talk:Cronus, User talk:Lizard King and Talk:Bigfoot --
I've never insulted him personally or broken any
Wikipedia policies that I'm aware of.  I didn't even
engage in an edit war, though UtherSRG did.  I believe
I reverted [[Cronus]] once, and scrupulously outlined
my reasoning on the talk page.  I may request a ban
soon, depending on how things go -- he has, after all,
edited my comments to make it appear as though I
agreed with him when I clearly did not and also that I
was sexually attracted to Bigfoot -- isn't that an
officially bannable action?

Tuf-Kat

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus


subject: [Wikitech-l] Re: Re: Secondary servers

body:
On Mon, 12 Jan 2004 20:16:27 -0800, Brion Vibber wrote:

> Scratch Carol off the list for now. Carol's also got 4GB of RAM which
> would be _very_ nice to have up and running, assuming it all works!

Are there unused cache slot on Ursula? If we could use some of this
ram we should be set i guess- Geoffrin also has 4 Gigs and didn't seem to
swap badly. Might be imcompatible ram though, don't know.

>
>> * Susan (currently idle) with another IDE drive that's likely not the
>> fastest.
>
> Susan hasn't died during memory testing yet (yay). However it's a
> smaller machine with only 512MB of memory as well as the ide disk. Not
> ideal for database, though this might be sufficient to offload some
> work.

Hm- could we stick some of Carol's ram into this one?

--
Gabriel Wicke


from_name: Charles Matthews

body:
Also being someone who reads this list without posting much, I was trying
for some perspective rather than intending to get involved.

In the abstract, I assumed that WP will always encounter problems in trying
to include everything; because writing contemporary history in the making is
not only contentious but probably based on sources that are incomplete.

The 'least bad' solution would seem to me to be a 'pendulum arbitration'
plus 'cooling-off' period mechanism for edit wars: someone decides which of
two versions is less unreasonable, and locks the page for a period of ten
days.  Here pendulum arbitration comes from labour disputes, where you don't
try to find the middle point (which encourages extreme positions) but choose
one or other side.

As for the Middle East, I had a look at some pages.  The coverage overall
seems creditable, but there does seem to be plenty of POV to work on.  I
looked at some RK edits and wasn't impressed.  Even if he's correct on the
balance of lack of NPOV (which might be true), I came away disliking his
advocacy.

Charles


from_name: Ricky Beam

body:
On Tue, 13 Jan 2004, Nick Reinking wrote:
>Also, it should be noted that if we want to extend the usefulness of
>current machines, there are some 10K Western Digital IDE drives
>(basically SCSI drives with an IDE interface).  They have an average read
>access time of 8.3ms (the WD740GD does, at least), and is $260 from
>Newegg for the same size (74GB).  It also has a built-in PATA-to-SATA
>bridge, so it supports hot-swapping and command queueing.

Indeed.  Those drives are "bastard stepchildren"... it's a SCSI servo with
IDE controller electronics tied to a SATA bus via a built-in bridge.  It's
a f'ing IDE drive.  Stay away from it.  If you want SATA (read: something
cheaper than SCSI), buy real, native SATA drives which only Seagate are
currently making. (which exact models, I don't know.)

Haven't we already had the "cheap is not the goal" mini-flame?  If you
want fast and reliable, it's gonna take some green.  If you want cheap,
it'll be less reliable and slow.  I would personally recommend a FC array
deployed under LVM2 with XFS riding on top.  The array is physically
expandable to 127 drives.  And the drives are really fast, esp. when you
have 100 of them in parallel :-)

--Ricky


body:
I don't think the notion of 'native English speaker' is a particularly
coherent one, when framed as the audience.  Much less so than 'users of
international scientific English', or francophones, for example.  It makes
sense to me to say that articles should be written in standard literary
English, and to international scholarly standards.

Charles


from_name: Nick Hill

subject: [Wikitech-l] Re: Re: Secondary servers

body:
Another important point which occurs to me;

The article size on Wikipedia varies dramatically but average 1400
bytes. The size of entries in the old table- the updates- are likely to
average even smaller.

By default, ext2/ext3 filesystem blocks tend to be 4k in size. I haven't
yet investigated how big cached disk pages are in the Linux kernel-
whether they mirror the size of filesystem blocks or are a multiple, or
are fixed in number and vary in size with available memory etc.

If the cache page size can be tuned to the data atom size (which I feel
it can, even if this needs a header value change + recompile) - that is
tuned to the  median average data size of articles, the number of
popular articles held in a given amount of ram can possibly be increased
by several fold. This will have a cost, perhaps not very big, in terms
of scheduler work load and, if the pages are very small, memory needed
by the kernel to administer a massive array of cache pages.

This solution would, nevertheless, be less optimal than a suitable solid
state storage solution for the busiest wikis.

Nick Hill wrote:

> I suggest four avenues for investigation:
> 1) Store articles in the MySQL table in compressed (gzip) format. This
> will reduce the size of the articles, making them fit more easily into
> the available cache memory, increasing the chances of a cache hit almost
> by a factor of two. Perhaps this can be made as a patch to MySQL.
> 2) Investigate ways of prioritising data cached in memory such that
> smaller chunks of data have a higher value than larger chunks so that
> smaller chunks are not flushed according to the basic least recently
> used algorithm. To reflect the relative cost of reading a small chunk of
> data from the HDD.
> 3) If the SQL code underlying wikipedia relies on temporary tables as
> part of the SQL queries, investigate whether the I/O of writing
> temporary tables tends to flush data from the disk cache. If so, write
> temporary tables to ramdisk or other storage which does not cause
> flushing. More recent versions of MySQL support sub-queries. This may
> obviate the need for temporary tables.
> 4) Judicious use of solid state storage. Could dramatically reduce seek
> times and I/O bottleneck. Some issues to resolve regarding flash memory
> durability and possible MySQL hotspots. Also cost of mass solid state
> storage. Might be worthwhile for some wiki data.
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>


body:
Poor, Edmund W wrote:

>Viajero wrote:
>
>>Adam Carr demonstrated on articles like [[Anti-zionism]] that it
>>seems to make a huge difference if ONE individual takes charge of
>>the article with no particular authority except the confidence of
>>other contributors. Adam is by no means impartial (who is?) but he
>>has a gift for synthesizing various POVs into an effective, well-
>>written organic whole.
>>
>I think this will work for any topic, provided an individual can be
>found who can win the confidence of the other contributors. I myself
>have managed to gain a degree of trust at [[Silesia]], and I have
>hopes that it may be sufficient to enable me to do in the Balkans
>what Viajeron suggests for the Middle East.
>
Agreed.  To gain that confidence you need to be seen as listening to
both sides of the dispute.  It's an approach that is superior to the VfD
process.  Starting a discussion with "I want to delete your article."
does not promote a collaborative approach to the problem.  It brings out
defensive attitudes.

Ec


from_name: Viajero

body:
A logical first step would be to try this scheme on one article as a test.
I would suggest taking perhaps the most controversial topic in the Middle
East, the Palestinian refugees.

There are now two articles on this topic:  [[Palestinian refugee]] and
[[Palestinian exodus]]. They overlap and should be merged into one; let's
call it [[Palestinian refugees]].

Adam Carr demonstrated on articles like [[Anti-zionism]] that it seems to
make a huge difference if ONE individual takes charge of the article with
no particular authority except the confidence of other contributors. Adam
is by no means impartial (who is?) but he has a gift for synthesizing
various POVs into an effective, well-written organic whole.

Taking Adam's very effective work mode as a starting point, let's have one
person take (temporary) responsibility for the article. What about Zero?
Any objections? Or another candidate? We protect the page and move all
work to [[Palestinian refugees/Draft]] and discussion to
[[Talk:Palestinian refugees/Draft]]. We give it a month and see what
happens

At this point, we have nothing to lose.

V.


from_name: Camille Constans

subject: [Wikitech-l] Wikipedia for the Zaurus

body:
On Sat, 10 Jan 2004 20:37:17 +0100
Markus Baumeister <markus at spampit.retsiemuab.de> wrote:

> Hello,
>
> I have modified Alfio Puglisi's wiki2static script and added a few of my own
> to generate a static compressed version of wikipedia which should be
> viewable on any UNIX-PDA featureing a webserver and a sh-compatible shell.
> Compression works quite nicely, I currently have the German and the English
> content (including media and TeX images) taking up up ca. 600MB on a
> microdrive. Since TomeRaider is not available for Linux-based PDAs this
> should fill the last non-Wikipedia hole. See
> http://www.retsiemuab.de/wiki2zaurus .
>
> Two questions:
> 1) Can some people (preferably with UNIX PDAs and desktops) check if the
> descriptions on the above site are understandable and work for them also?

It is possible to have an all in one package ? To download to the zaurus.
Does it works on Openzaurus ?
I'm ready to try, I would prefer a french edition :)

> 2) Should I put a link on a wikipedia page and if yes on which one?
> "Wikipedia:Database download" has the links to the wiki2static script but I
> would rather not be listed on a page about how to get database dumps.
> Without necessary bandwidth for offering dumps I'd prefer to distribute only
> scripts.

Do it and if somebody doesn't like he will remove it :)

Shaihulud


subject: [Wikitech-l] Secondary servers

body:
Jimmy Wales wrote:

>
> I think others have said this, but I think you're behind the times
> when you talk about a "ramdisk".  We're not running DOS here.  Linux
> will already cache as much as it can in memory, and in a sensible and
> automatic way.
>
> But realistically speaking, this is not a bottleneck worth trying to
> solve.  When it's working, the db server is very fast, and already
> holds everything that it needs in memory, as far as I know.

I understood the server was I/O bound from a recent posting. Server
maxed out with low CPU utilisation. The information you and I have
differs. You are in a position to have better information on this than
I. I certainly don't want to waste time solving a non-existent problem.

Do we have a bottleneck? If so, where is it and how do we know?


subject: [WikiEN-l] Shades of Rashomon (was: Re: This is getting ugly)

body:
On 01/12/04  at 08:35 AM, Fred Bauder <fredbaud at ctelco.net> said:

> Generally, although I would not expect you to admit it, Wikipedia
> articles have a somewhat pro-Israeli bias.

Several of us were discussing the topic on the IRC channel in December
(Anthere may remember this because she was one of them) and this question
came up. One person said they thought WP (EN) had a pro-Israeli bias.
Another said a pro-Palestinian bias. A third said neither POV was
accurately represented.

Conclusion???

> There just aren't a lot of
> Arabs or Palestinians showing up here. Most pro-Palestinian edits are
> coming from a liberal Israeli point of view such as Danny's

One Palestinian-Canadian showed up awhile ago but alas he has not
contributed since September:

http://en.wikipedia.org/w/wiki.phtml?title=Special:Contributions&limit=500&offset=0&target=Joseph_E._Saad

V.


subject: [Wikitech-l] Secondary servers

body:
Nick Hill wrote:
> Do we have a bottleneck? If so, where is it and how do we know?

Jimbo answered this at 13:18. Messages crossed in the mail.


subject: [Wikitech-l] The order

body:
At that price, they should send a technician to install it, test it, and
hang around for a few days to make sure it "burns in" all right.

Ed Poor


list: wikipedia-l

from_name: Frederic Malo

subject: [Wikipedia-l] trouble with gzip2 downloads

body:
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20040113/e9b6fcc5/attachment.htm


from_name: Gabriel Wicke

subject: [Wikitech-l] Re: Secondary servers

body:
On Tue, 13 Jan 2004 13:29:51 +0000, Nick Hill wrote:

>
> Do we have a bottleneck? If so, where is it and how do we know?

The temporary server doesn't have enough ram, that's all. Geoffrin has 4Gb
and worked fine, adding more ram to Ursula would do the same.

--
Gabriel Wicke


from_name: Nikos-Optim

body:
yes, all Wikipedias are international.

English Wikipedia is intented for all people who can
read English.

Greek Wikipedia is intented for all people who can
read Greek.

There is no discrimination between Native and
Non-Native speakers. Let's get rid of discriminations.

--Optim

--- tarquin <tarquin at planetunreal.com> wrote:
>
>
> Anthere wrote:
>
> >
> > I do not like the concept of "first" and "second"
> audience because
> > that would be officially stating that we should
> primarily write for
> > the first, to the detriment of the second.
> >
> > * First because as you stated it, english (along
> with spanish
> > possibly) is international language. It is the
> most international of
> > all languages. Potentially, it can reach many many
> more people than
> > just native english speakers. Whether you want it
> or not, english is
> > not entirely your language anymore. It is our
> common language. The one
> > we can share. The one that can be a babel tower so
> we can understand
> > all together.
> >
> I agree with Anthere.
> In terms of material and content, we should consider
> the audience of all
> wikipedia languages to be international.
> (Naturally, in terms of the vocabulary and grammar,
> we write for
> competent speakers of the language.)
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus


from_name: zero 0000

body:
Viajero wrote:
> > Adam Carr demonstrated on articles like
> [[Anti-zionism]] that it
> > seems to make a huge difference if ONE individual
> takes charge of
> > the article with no particular authority except
> the confidence of
> > other contributors. Adam is by no means impartial
> (who is?) but he
> > has a gift for synthesizing various POVs into an
> effective, well-
> > written organic whole.

Ed replied:
> I think this will work for any topic, provided an
> individual can be
> found who can win the confidence of the other
> contributors.

I reply:
This is quite correct, but it is also temporary.
As soon as the respected moderating person goes
away, the fighting will flare up and by the end
of the first good edit war the results of all
that hard work will have been swept away.
I suggest that my proposed change would make
this (slightly) less likely to happen.

Zero

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus


subject: [Wikitech-l] Re: Secondary servers

body:
On Tue, 13 Jan 2004 05:46:15 -0800, Jimmy Wales wrote:

> I'm putting the finishing touches on an order at Silicon Mechanics right
> now, and I'll report back to everyone once I have all the details and a
> firm delivery date promise.

Jimbo-

how much ram are you going to order for the Squids? I've read that it's
possible to address more than 4Gigs though highmem on x86, but only 3
Gigs per process. Squid is a single-thread asynchronous app, so this is a
limit. Is there a major price penalty in a single-processor 64bit CPU?
Having enough ram for all content on the Squids is a good thing for both
speed and reliability- not an immediate problem for now, but it might get
one as wikipedia grows. On the other hand x86 Squids could be converted to
Apaches later if they are the same kind of machine.

The ram issue propably also applies to the DB server, but i guess you'll
order 64bit anyway for that.

--
Gabriel Wicke