subject: [Wikipedia-l] flood warning

body:
Hello,

we begin to face massive anonymous / non-anonymous contributions on
topics related to one another such as nationalism, racism, racialism in
a clearly oriented direction.

example new definition :
Le nationalisme est une politique dont les objectifs sont
essentiellement l'ind?pendance, l'unit? et la prosp?rit? de sa propre
nation et de son peuple.

Nationalism is a policy whitch goals are essentialy the independance,
the unity and the prosperity of its own nation and people.

(sic but not the problem) No mistakes in translation "own nation" refers
to policy.

We have many "anonymous" rewriting of sensible topics such as
racialism, and racism

For instance, now, we explain why racism is totally understandable and
acceptable especialy on a scientific point of view. The definition had
had its change totally re-oriented without any discussions.

These people don't intend to respect the moral contract of wikipedia.
Wake-up  if you just let it happen, you will face quite a problem. Now
it is easy to face 3 people with a current team of ~20 active
contributors, but when it will be twice as the original contributors you
might be quite annoyed.

I know I'll get the blame for being alarmist and ?paranoid?, but please
if you are not convinced just wonder  what if it was true ?  True, that
we get these people trashing all the wikipedia project's spirit and part
of the content, wouldn't it worth a try to imagine the solution we can
consider to face that problem ?

PS: Sorry for not respecting the netiquette and posting so much so soon.

--
Julien Tayon
http://www.tayon.net/			       http://libroscope.org/
Si la v?rit? est une femme, essayons de la s?duire avant de la saisir.


list: wikitech-l

source: pipermail-mbox

from_name: Erik Moeller

subject: Spin-off software (was Re: [Wikitech-l] "View user page" edit links on anon talk pages)

body:
> So, when we talk of making the wikipedia software more general (and
> faster, of course;-), is anyone opposed to throw in some *possible*
> restrictions for, say, editing, uploading etc.? They'll be off by
> default, so wikipedia won't change a bit, but we could use the same code
> with a few changed variables for the Sifter.

No objections - just a few more "if($wgSomeGlobalVar)"s I guess. But
perhaps you could post a more detailed proposal of what you want to change
and how.

Also, I still think that a well-integrated, generalized group
certification system makes more sense than a separate filter project.

Regards,

Erik


list: wikien-l

from_name: Sheldon Rampton

subject: [WikiEN-l] Re: Challenge to Sheldon Rampton re: global warming

body:
Ed Poor wrote:

>  > Hey, speaking of disingenuous answers, how about applying the NPOV to the
>>  [[global warming]] article? Are you able to step back from your advocacy and
>  > be neutral for a few minutes, and help us make a balanced article there?

And Erik Moeller replied:

>Ed, why this personal attack ("speaking of disingenuous answers"), and why
>on the mailing list? "Step back from your advocacy" - which advocacy?
>Sheldon has not made a single edit to the global warming article. His last
>major contribution is from a week ago and unrelated. Since Sheldon joined
>the project, you have repeatedly attacked him, also on Talk pages.

Thanks, Erik, for rising to my defense. I should point out, however,
that I *have* made a "single edit" to the global warming article. I
made the edit on December 18 under IP # 208.171.49.198. It's a fairly
minor edit, and I wasn't logged in under my user ID at the time
because I had only begun using Wikipedia a few days previously and
wasn't accustomed yet to the habit of logging in.

I must say, though, that I find it remarkably hypocritical for Ed to
accuse *me* of being disingenous with regard to inserting a POV. I'm
not going to debate him here about the scientific evidence on global
warming, but it's very clear that he has been assiduously lobbying to
inject his point of view into the article - a point of view that he
expressed quite clearly in the Talk page, where he stated, "The whole
global warming thing is a hoax, and 'warmers' have used statistical
manipulation (i.e., lied) to bolster their arguments." Clearly, when
someone resorts to calling other people liars, that's a strong point
of view, and virtually every edit that Ed has made to this article is
an attempt to inject this point of view by challenging the
scientificity of the global warming hypothesis and impugning the
motives of its proponents.

Ed has also injected a point of view into his articles about Sun
Myung Moon and the Unification Church. The article about Moon reads
more like worshipful hagiography than a serious attempt at biography.
It gushes about his "cheerful attitude" and "intolerance of
injustice," and states that Moon "had a vision or revelation of Jesus
Christ while praying on top of a tall hill," as though this were a
documented fact. The article on "Sun Myung Moon/tax case" consists
primarily of Moon's defense arguments and even includes a
first-person statement by Ed in which he first states as fact an
undocumented claim that the government made an offer to "drop all the
charges," and then writes that this is "a story circulated among us
UC members." It's clearly POV and a violation of Wikipedia policy to
inject first-person commentary based on church gossip into the actual
text of articles.

These examples demonstrate a dilemma that is bound to arise
occasionally when attempting to write from a "neutral point of view."
When someone believes passionately in their point of view (as Ed
clearly does with regard to both global warming and the Unification
Church), it becomes difficult for them to distinguish between their
strongly-held beliefs and a NPOV. In the case of Rev. Moon, Ed seems
incapable of even *attempting* to draft a neutral text. In the case
of global warming, his version of "neutrality" consists of tortured
equal weight to skeptics and global warming proponents alike, while
constantly impugning the alleged "environmentalist bias" of global
warming proponents. In reality, this forced "balance" is no more
inherently neutral than it would be for Wikipedia to give Nazi
Holocaust deniers the same weight and credence as it gives to
Holocaust historians, while insinuating that the people who believe
in the Holocaust are Jews and Jew-lovers.

I don't fault Ed for having some ideological blind spots. I'm sure I
have my own. However, I strongly disagree with his absurd notion that
I have some personal responsibility to do his dirty work for him by
inserting arguments with which I do not agree into the global warming
article. He wrote:

>One of the best ways to attain neutrality in a contentious article
>is for a person who believes passionately in one side to focus on
>making the best case for the OTHER SIDE. If you could do this, it
>would be a big help.

Since I am sure that Ed doesn't want us to think he's a hypocrite, I
am sure that he will set an example for us all by editing his
articles about Rev. Moon so that they "focus on making the best case"
for arguments that Moon is a fraud, tax cheat, manipulative cult
leader, failure as a father and behind-the-scenes backer of
Nicaraguan contras and North Korean politicians who lives in
ostentatious wealth while expecting his followers to live in poverty.
I would do this myself, except that I'm not really interested in
writing about the Unification Church. And since Ed "believes
passionately" in his church, one of the "best ways to attain
neutrality" would be to have him be the one who makes these arguments.
--
--------------------------------
|  Sheldon Rampton
|  Editor, PR Watch (www.prwatch.org)
|  Author of books including:
|     Friends In Deed: The Story of US-Nicaragua Sister Cities
|     Toxic Sludge Is Good For You
|     Mad Cow USA
|     Trust Us, We're Experts
--------------------------------


subject: [WikiEN-l] Clutch/Jonathan and the mystery of NPOV

body:
All,

please take a look
at

http://www.wikipedia.org/w/wiki.phtml?title=Richard_Wagner&diff=0&oldid=634297

I believe this edit speaks for itself. Notice that this edit was labeled as
"restoring an URL and working toward a compromise on POV issues". A
"compromise" (after his previous drastic POVification of the article) which includes
the unexplained removal of plenty of significant information and obviously
POV statements such as:

"Labelling Wagner as an anti-Semite is misleading; he never supported
violence against Jews, nor did he hold them to be at fault for the cultural divide
that he perceived existed between German Jews of his time, and mainstream
German culture."

Once more, Clutch is trying to whitewash Wagner of any and all anti-Semitism
(the "accusations" of which he believes are only made by Jews.) Frankly, I'm
fed up by his edits. I can see absolutely no reason why Lir is banned and he
is not. Enough is enough.

Regards,

Erik

--
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr f?r 1 ct/ Min. surfen!


subject: [WikiEN-l] Challenge to Sheldon Rampton re: global warming

body:
> Hey, speaking of disingenuous answers, how about applying the NPOV to the
> [[global warming]] article? Are you able to step back from your advocacy and
> be neutral for a few minutes, and help us make a balanced article there?

Ed, why this personal attack ("speaking of disingenuous answers"), and why
on the mailing list? "Step back from your advocacy" - which advocacy?
Sheldon has not made a single edit to the global warming article. His last
major contribution is from a week ago and unrelated. Since Sheldon joined
the project, you have repeatedly attacked him, also on Talk pages. Are you
afraid that there's someone who actually sees through the global warming
spin and trying to drive him away?

You have made plenty of dubious edits to the global warming articles. For
example, you recently replaced the intro with

* * *
"The belief that global warming is caused chiefly by emissions of [[carbon
dioxide]] and other other '[[greenhouse gas]]es' is promoted by
environmentalist organizations and supported by most Western journalists.

"The proportion of scientists who support or oppose any of the various
global warming theories is a matter of controversy in its own right.
Environmentalists and their allies claim virtually unanamious support for
the global warming theory from the scientific community. Opponents
maintain that it's the other way around, claiming that the overwhelming
majority of scientists either dismiss global warming altogether or merely
consider it "unproven" (see [[global warming scepticism]]). "
* * *

I have asked you for a reference especially for the last sentence, and the
placement of the "promoted by enviros and journos" part as second
paragraph of the article was clearly not NPOV. You have rarely defended
your edits at all, and not provided references. On the Talk page of
[[Global warming]] some people now almost refuse to talk to you at all
because of your past edits.

You usually do a good job at maintaining NPOV and a professional attitude.
Why does it seem to fall apart with this issue? Is it because your beloved
Unification Church is so heavily promoting the idea that global warming is
a myth over the church-owned Washington Times and the SEPP PR group /
"think tank" and its leading pseudoscientist Fred Singer? Are you, pehaps,
complying with "higher orders"?

Regards,

Erik


body:
> Erik, I encourage you to research your facts before criticizing me
> publicly.  If you have questions about my edits, perhaps a more amiable
> forum for discussing them would be on the appropriate Talk page.  I am
> always open to honest criticism.

This is what I referred to on [[Talk:Richard Wagner]]: Always trying to
weasel out, always returning any criticism, concentrating on one
particular "enemy", trying to single him out as being biased (with wrong
statements, once again, which I will not bother to refute), trying to
portray a particular error as a "controversy" with a "few" other people,
trying to portray yourself as the nice fellow who can work with everyone
if given enough time. I enjoyed your following statement: "I will always
be able to defend my edits". I have no doubt about that.

Sorry, Jon, but that strategy, while quite sophisticated, is not going to
work forever.

Regards,

Erik


subject: [Wikitech-l] Optimizing and tuning

body:
There are two very good IRC channels on irc.freenode.net:

#php and #mysql

There are lots of knowledgeable people there who are eager to help open
source projects, many have already heard of Wikipedia. I learned a lot
from just being there for half an hour or so.

Here are some things we need to look into:

1) Composite indexes and index use in general. I do not know which indexes
are currently used on the live Wikipedia. However, after the *default*
database generation script, there is just a single composite index, namely
in the table watchlist. All other indexes are on a single field. If I
understand correctly, this means that when we do a query with multiple
comparisons, e.g. WHERE foo=bar AND baz=bat, only one index is used. At
least, that is what this article claims:

http://www.linux-mag.com/cgi-bin/printer.pl?issue=2001-06&article=mysql

There are also a couple of tables with no indexes (including ARCHIVE,
which may cause Special:Undelete to create high server load) and some
unexplainable ones (site_stats has an index, but only one row). We really
need to clean up our indexes. I can't help much with this without server
access because I don't know if the table structures have been altered.

2) The HANDLER command. HANDLER, which works with both InnoDB and MyISAM,
provides low-level access to tables *without locking*. You get reads, but
you don't get consistency, which may cause problems when you're dealing
with critical, heavily modified data. But it seems perfect for our archive
stuff. The HANDLER syntax is explained here:
http://www.mysql.com/doc/en/HANDLER.html

We definitely should look into this.

3) Upgrading to MySQL4. MySQL4 supports query caching (also subqueries,
but I haven't looked into that), which means that heavily queried pages
will load faster. When someone mentioned query caching, a lot of other
people made comments like "query caching rocks", so I assume it provides
quite some performance benefits in practice.

4) Tuning my.cnf. According to one IRC resident, upping table_cache can
greatly increase performance with lots of UPDATEs. If we create new
indexes, we may also need to raise index_cache (there's a formula to
calculate your index cache efficiency, currently we are at 99.75%, which
is pretty good).

5) Caching our article index. I have mentioned this idea before, I think:
We could just keep our entire article index in memory *persistently*
(currently the linkcache is filled for each request), which should make
link lookup almost instant. There are several ways to accomplish this:

- We could ask one of our resident C programmers to help. There's a
specified interface to access persistent resources in MySQL, which is used
by functions such as mysql_pconnect. This page describes how it works:
http://www.php-center.de/en-html-manual/phpdevel.html

- We could use session variables for the purpose. There is supposed to be
an option to keep session stuff in shared memory. This might help with
other caching problems as well.

- We could just put a database on a ramdisk for this purpose.

The order of this list reflects the priority at which I think these
different questions need to be addressed. Getting our indexes to work
properly should IMHO be of greatest importance. Even if EXPLAIN shows the
use of an index, we may frequently still require large table scans because
we do not use composite indexes.

Regards,

Erik


list: wikipedia-l

from_name: Guillaume Blanchard

subject: [Wikipedia-l] Racialisme

body:
> Guillaume Blanchard wrote:
> > I said this word is not french, so we have to think about how to
> > handle this kind of case.
> > And what is the criteria that make a word that don't exist
> > officially can be add in an encyclopedie or not ?
>
> The "culture" of English is very different from the "culture" of
> French in this regard.  What I mean is, the idea that a word doesn't
> exist "officially" is a very odd idea to English speakers.  Words
> exist when people use them and know what they mean.
>
> I recommend using a variety of factors in determining whether or not a
> word is a "real word" for the purposes of the Encyclopedia.  Whether
> or not it is in a dictionary is certainly _one_ factor that's worth
> considering.  But common usage is also important, probably more
> important, isn't it?

I agree. It's why I finally wrote an article on Racialisme.

> --Jimbo


subject: [Wikitech-l] Optimizing and tuning

body:
Correction:

> - We could ask one of our resident C programmers to help. There's a
> specified interface to access persistent resources in MySQL

Resources in PHP, not MySQL. The MySQL pconnect functions are an example
that uses this interface.

Regards,

Erik


from_name: Daniel Mayer

subject: [Wikitech-l] What to do with Meta?

body:
On Saturday 01 February 2003 04:00 am, Erik Moeller wrote:
> Um .. how about just getting rid of it? Why is it within Wikipedia's
> mission to somehow provide storage space for personal essays? We're an
> encyclopedia, not a hosting provider.

Let me repeat:
 If POV material isn't allowed on meta then where should it go?

Would it be better for Saprtacus to still be on en.wiki's Recent Changes?
Again, create another namespace and then you can filter your view of meta's
Recent Changes so would only see changes made to entries in those namespaces.

--mav


from_name: Jonathan Walther

body:
On Sat, Feb 01, 2003 at 09:45:18AM -0500, The Cunctator wrote:
>> I have to rise to Ed's defense.  I have only seen Ed trying to make sure
>> all sides of the story are represented.  Presenting global warming as a
>> scientifically proven "fact" is disengenous, dishonest, and unethical.
>> It is a popular theory, yes.  But it is also a controversial one.  I
>> have every confidence in Ed's neutrality.
>>
>Anthropogenic global warming, by the standard scientific definition of
>"fact", is a fact.

You didn't read the two URL's I cited, did you.  And your "fact" is
debatable.  Indeed, myself and many others do debate it.

Jonathan

--
                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw at reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030201/47c09261/attachment.pgp


from_name: Cunciforme

subject: [Wikipedia-l] flood warning

body:
--- julien tayon <julien at tayon.net> wrote:
> Hello,
>
> we begin to face massive anonymous / non-anonymous
> contributions on
> topics related to one another such as nationalism,
> racism, racialism in
> a clearly oriented direction.
>
> example new definition :
> Le nationalisme est une politique dont les objectifs
> sont
> essentiellement l'ind?pendance, l'unit? et la
> prosp?rit? de sa propre
> nation et de son peuple.
>
> Nationalism is a policy whitch goals are essentialy
> the independance,
> the unity and the prosperity of its own nation and
> people.
>
> (sic but not the problem) No mistakes in translation
> "own nation" refers
> to policy.
>
>
> We have many "anonymous" rewriting of sensible
> topics such as
> racialism, and racism
>
> For instance, now, we explain why racism is totally
> understandable and
> acceptable especialy on a scientific point of view.
> The definition had
> had its change totally re-oriented without any
> discussions.
>
> These people don't intend to respect the moral
> contract of wikipedia.
> Wake-up  if you just let it happen, you will face
> quite a problem. Now
> it is easy to face 3 people with a current team of
> ~20 active
> contributors, but when it will be twice as the
> original contributors you
> might be quite annoyed.
>
> I know I'll get the blame for being alarmist and
> ?paranoid?, but please
> if you are not convinced just wonder  what if it was
> true ?  True, that
> we get these people trashing all the wikipedia
> project's spirit and part
> of the content, wouldn't it worth a try to imagine
> the solution we can
> consider to face that problem ?
>
> PS: Sorry for not respecting the netiquette and
> posting so much so soon.

Et pourquoi ne pas traiter autrui comme si il ?tait en
train de contribuer ? l'effort collectif ?

Une contribution anonyme peut ?tre extr?mement
b?n?fique, tout comme une contribution attribu?e peut
?tre source de d?sagr?ment.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


subject: [WikiEN-l] Our own extreme POV sometimes makes it impossible for us to write NPOV prose

body:
On Saturday 01 February 2003 04:00 am, Clutch wrote:
>....
> I have no religious or ideological motivation for saying this, but I too
> have read both sides of the story and agree with Ed the global warming
> as an unprecedented and imminent disaster seems like a grand hoax.
>....

With friends like you Ed doesn't need enemies:

Well Clutch you also think there is a grand conspiracy with the US government
poisoning the American people by adding fluoride to their drinking water. And
on top of that you think that the Apollo Moon landings were a hoax. In
addition there doesn't seem to be an anti-Semite you didn't like (thinking of
the considerable work you have done to absolutely minimize that aspect of
Richard Wagner and now Henry Ford). Oh and your work on [[Jehovah's
Witnesses]] and daughter articles is Witness-friendly enough for publication
in WatchTower. So IMO your above words carry very little weight - at least
for me.

With that said, I do think that Ed's POV in regards to global warming and the
Unification Church is too great for him to make substantial changes to those
articles without unintentionally violating NPOV. For example, I know my POV
on homosexuality is too great to make any changes greater than adding or
modifying a paragraph in the homosexuality-related articles.

Some issues are simply hot buttons for people and for the sake of NPOV we
should voluntarily not make substantive changes to those articles (otherwise
we unconsciously give our POV too much weight in articles).  Of course there
are rare people like Montrealais who in spite of his strong POV on gay issues
is able to make what is IMO NPOV contributions in that area.

We should all understand that the ability to 'write for the enemy' is
difficult and that trying to write for your mortal enemy whom you absolutely
despise is very difficult and impossible to do correctly for most people.

--mav

WikiKarma:
Added more events to [[January 29]] and updated all the year pages and many
other articles linked from that page.


from_name: Brion Vibber

subject: [Wikitech-l] Optimizing and tuning

body:
On sab, 2003-02-01 at 07:44, Erik Moeller wrote:
> > Adding composite indexes won't help there. What you need is an extra
> > redundant table that contains the number of wanted links.
>
> We have a table that contains broken links, which is used in the Most
> Wanted query. I have no information about the size of these tables in our
> current database, but I suspect that, again, indexes are not properly
> used, otherwise the bad performance of this query (which has prompted
> Magnus to cache the whole page and Brion to create a "miser" mode in which
> it cannot be loaded) is not explainable.

EXPLAIN
  SELECT bl_to, COUNT( DISTINCT bl_from ) as nlinks
  FROM brokenlinks
  GROUP BY bl_to
  HAVING nlinks > 1
  ORDER BY nlinks DESC
  LIMIT 0, 50;
+-------------+-------+---------------+-------+---------+------+--------+---------------------------------+
| table       | type  | possible_keys | key   | key_len | ref  | rows   | Extra                           |
+-------------+-------+---------------+-------+---------+------+--------+---------------------------------+
| brokenlinks | index | NULL          | bl_to |     255 | NULL | 319493 | Using temporary; Using filesort |
+-------------+-------+---------------+-------+---------+------+--------+---------------------------------+

The problem is that it has to count up *every* row, then sort based on
the counts just to return the top 50. The grouping may be sped up by the
index, but it's still going to be a bit of work. (Just tried it, took
37.59 seconds.)

Jan has suggested having a summary table that keeps track of the counts,
so we can access them directly. I'm inclined to agree; we could update
it on page saves (and deletes and renames and undeletes!) to save the
bother of the group/count/sort behemoth. Something like:

CREATE TABLE wantedpages (
  wanted_title varchar(255) binary NOT NULL default '',
  wanted_count int unsigned NOT NULL default 0,
  UNIQUE KEY wanted_title,
  INDEX wanted_count
);

Index on the count, certainly, to speed the sort for the most wanted
display. Index on the title should speed picking the right ones on
updates, right?

Anyway, this would turn the most wanted query into:

  SELECT wanted_title,wanted_count
  FROM wantedpages
  WHERE wanted_count > 1
  ORDER BY wanted_count DESC
  LIMIT 0, 50;

which should be quite a bit faster.

I suspect we can be smarter about how we update links and brokenlinks as
well; currently we just delete every row pertaining to the page we're
dealing with and re-insert it.

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


from_name: The Cunctator

body:
On 2/1/03 2:09 AM, "Jonathan Walther" <krooger at debian.org> wrote:

> I have to rise to Ed's defense.  I have only seen Ed trying to make sure
> all sides of the story are represented.  Presenting global warming as a
> scientifically proven "fact" is disengenous, dishonest, and unethical.
> It is a popular theory, yes.  But it is also a controversial one.  I
> have every confidence in Ed's neutrality.
>
Anthropogenic global warming, by the standard scientific definition of
"fact", is a fact.


from_name: rednblack at alum.mit.edu

in_reply_to:
Your message of "Sat, 01 Feb 2003 09:45:18 EST."
             <BA6147AE.6726%cunctator@kband.com>

body:
Actually, anthropogenic warming is NOT a fact, it is only a theory, and not a
very well-established one at that. The IPCC studies get a lot of play, but they
are by no means definitive, and the models used to demonstrate the point are by
no means perfect. Global warming is well-established, other claims to the
contrary, and few people studying this dispute that significant warming is
actually happening. However, there are pretty significant weaknesses in the
models that predict warming from anthropogenic sources, like their failure to
accurately predict warming rates. There's a case to be made that anthropogenic
sources of warming are important, but I wouldn't call it a "fact" yet, like I
would say that something like relativity or Coulomb's law is a "fact".

Anyway, this is getting way off-topic for this mailing list and belongs on
[[Talk:Global warming]], where it can actually do some good.

Saurabh (Graft)

------
"It doesn't matter what government the country has.  The power is held by those
 who own and control medias." -- Ahmed Rami

In message <BA6147AE.6726%cunctator at kband.com>, The Cunctator said:
>On 2/1/03 2:09 AM, "Jonathan Walther" <krooger at debian.org> wrote:
>
>> I have to rise to Ed's defense.  I have only seen Ed trying to make sure
>> all sides of the story are represented.  Presenting global warming as a
>> scientifically proven "fact" is disengenous, dishonest, and unethical.
>> It is a popular theory, yes.  But it is also a controversial one.  I
>> have every confidence in Ed's neutrality.
>>
>Anthropogenic global warming, by the standard scientific definition of
>"fact", is a fact.
>
>_______________________________________________
>WikiEN-l mailing list
>WikiEN-l at wikipedia.org
>http://www.wikipedia.org/mailman/listinfo/wikien-l
>


subject: [Wikitech-l] Re: Optimizing and tuning

body:
On sab, 2003-02-01 at 07:12, Jan Hidders wrote:
> Sorry for replying to myself, but I just saw in CVS that the SQL is
> something like this:
>
>   SELECT HIGH_PRIORITY cur_id
>   FROM cur
>   WHERE cur_namespace=" . "{$ns} AND cur_title='" . wfStrencode( $t ) . "'";
>
> but if I look in buildTables.inc we have a separate index for namespace and
> title. That should really be a combined index and that holds for everywhere
> we do a look-up with namespace + title. Do we have those?

Combined index might make sense. In most cases it won't significantly
cut down the number of rows, but for some (main page, current events,
user:maveric149) it could take out a couple hundred rows by splitting
the page and talk page.

Also, a vaguely related question on the watchlist query. Currently the
return-whole-watchlist query looks like:
SELECT DISTINCT
  cur_id,cur_namespace,cur_title,cur_comment,
  cur_user,cur_user_text,cur_timestamp,cur_minor_edit,cur_is_new
  FROM cur,watchlist
  WHERE wl_user={$uid} AND wl_title=cur_title
        AND (cur_namespace=wl_namespace OR cur_namespace=wl_namespace+1)
  ORDER BY cur_timestamp DESC {$dolimit}

I did an 'explain' using my uid. (I have 1370 titles in my watchlist;
the larger # of estimated returned rows is presumably due to the weird
InnoDB optimizer, which is known to return sometimes-wrong numbers of
rows.)

+-----------+------+-------------------------+-----------+---------+--------------------+------+----------------------------------------------------------+
| table     | type | possible_keys           | key       | key_len | ref                | rows | Extra                   |
+-----------+------+-------------------------+-----------+---------+--------------------+------+----------------------------------------------------------+
| watchlist | ref  | wl_user                 | wl_user   |       4 | const              | 3264 | where used; Using index; Using temporary; Using filesort |
| cur       | ref  | cur_namespace,cur_title | cur_title |     255 | watchlist.wl_title |    1 | where used                    |
+-----------+------+-------------------------+-----------+---------+--------------------+------+----------------------------------------------------------+

Is there a better way of doing this? We have a combined namespace/title
index on watchlist; but we want to pick up two variants in the
namespace. In most cases, just using the title as index on cur should
then be sufficient (it's relatively rare for titles to exist in multiple
groups of namespaces, mostly just in one namespace and the X_talk: next
to it).

> And I'm not sure if we really need the resulting cur_id. If we don't, then
> indeed only the index is needed and that would really speed up the query.

99% of the time, we don't; we're just checking for existence. It should
be sufficient to just have a boolean 'exists/doesn't exist' field. When
we're checking existence, is it most efficient to SELECT the indexed
field, or COUNT(*), or what?

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


subject: [Wikitech-l] Optimizing and tuning

body:
On sab, 2003-02-01 at 10:31, Jan Hidders wrote:
> Btw., shouldn't namespace be in there somehwere or is that still a
> part of the title?

On the link tables, the title strings include the (text) namespace. That
might not be the best way about it, though.

(For that matter, the links table should probably just be
cur_id-to-cur_id, so we can grab the titles & namespaces on a join. Or
is it useful to store it separately?)

> > I suspect we can be smarter about how we update links and brokenlinks as
> > well; currently we just delete every row pertaining to the page we're
> > dealing with and re-insert it.
>
> Probably, because when a page is saved you have to retrieve the "old" broken
> links from the DB anyway because there is no other way of knowing them and
> you need them to updated the wantedpages table. So you might as well compare
> them to the new list of broken links and remove/add only what has changed,
> which is usually only a few links anyway.

Sounds reasonable.

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


from_name: Takuya Murata

subject: [Wikitech-l] cvs diff

body:
This question is probably stupid, but why does it take
forever to do cvs diff? Is it my problem, configuration or
something?

Takuya Murata


subject: [Wikitech-l] Re:  "View user page" edit links on anon talk pages

body:
> I agree with Anthere and strongly disagree with eliminating personal essays
> from meta. If POV material isn't allowed on meta then where should it go?

Um .. how about just getting rid of it? Why is it within Wikipedia's
mission to somehow provide storage space for personal essays? We're an
encyclopedia, not a hosting provider.

Taku is correct in that this only makes Meta hard to use, especially for
other people who want to help working on the Wikipedia software. While it
is possible to better organize meta, the Recent Changes list is cluttered
by this stuff. There are literally hundreds of entries like this:

...
# diff) (hist) . . MN Meta-symbiosis; 15:25 . . Saprtacus
# (diff) (hist) . . M User talk:Saprtacus; 15:43 . . Saprtacus
# (diff) (hist) . . M User talk:Saprtacus; 15:39 . . Saprtacus
# (diff) (hist) . . M User:Saprtacus; 15:38 . . Saprtacus
# (diff) (hist) . . MN Meta-etiology; 15:33 . . Saprtacus
# (diff) (hist) . . M User talk:Saprtacus; 15:31 . . Saprtacus
...

Now try to find the critical "How Wikipedia can be really, really fast"
development proposal hidden deep within this idiosyncratic nonsense.

Regards,

Erik


from_name: Jan Hidders

subject: [Wikitech-l] Optimizing and tuning

in_reply_to: <8f0MJReCpVB@erik_moeller>; from erik_moeller@gmx.de on Sat, Feb 01, 2003 at 02:15:00AM +0100

body:
On Sat, Feb 01, 2003 at 02:15:00AM +0100, Erik Moeller wrote:
> There are two very good IRC channels on irc.freenode.net:
>
> #php and #mysql
>
> There are lots of knowledgeable people there who are eager to help open
> source projects, many have already heard of Wikipedia. I learned a lot
> from just being there for half an hour or so.
>
> Here are some things we need to look into:
>
> 1) Composite indexes and index use in general. I do not know which indexes
> are currently used on the live Wikipedia. However, after the *default*
> database generation script, there is just a single composite index, namely
> in the table watchlist. All other indexes are on a single field. If I
> understand correctly, this means that when we do a query with multiple
> comparisons, e.g. WHERE foo=bar AND baz=bat, only one index is used.

That is correct, and you could be right about this (I don't know what the
current database schema looks exactly like, but last time I was involved
this was still ok.) But keep in mind that a composite index also adds a lot
of overhead for updates, takes up more room in the index cache, and doesn't
really add much speed if the extra columns don't have a high selectivity,
i.e., filter out many unwanted records.

> 2) The HANDLER command. HANDLER, which works with both InnoDB and MyISAM,
> provides low-level access to tables *without locking*. You get reads, but
> you don't get consistency, which may cause problems when you're dealing
> with critical, heavily modified data. But it seems perfect for our archive
> stuff.

If there are not many updates then this accomplishes next to nothing, except
that you have made the software more complicated.

> 3) Upgrading to MySQL4.

Actually I was once in favour of that but Lee convinced me that as long as
the developers of MySQL don't think it is ready for production, we shouldn't
either. There is only one thing more important than speed and that is
stability.

> 5) Caching our article index. I have mentioned this idea before, I think:
> We could just keep our entire article index in memory *persistently*
> (currently the linkcache is filled for each request), which should make
> link lookup almost instant.

What makes you think it isn't already? I suspect the biggest part of the
involved tables is in the cache anyway, so it is probably pretty fast
already. So again, please make sure that this is really worth making the
software harder to understand. Keeping the software straightforward and
understandable and for newcomers that also want to help with programming is
a big priority for any open source project.

-- Jan Hidders

 .---------------------------------------------------------------------.
 | Post-doctoral researcher               e-mail: jan.hidders at ua.ac.be |
 | Dept. Math. & Computer Science         tel: (+32) 3 820 2427        |
 | University of Antwerp, room J1.06      fax: (+32) 3 820 2421        |
 | (UIA) Universiteitsplein 1, B-2610 Wilrijk - Antwerpen   (Belgium)  |
 `---------------------------------------------------------------------'


subject: [Wikitech-l] Optimizing and tuning

body:
> That is correct, and you could be right about this (I don't know what the
> current database schema looks exactly like, but last time I was involved
> this was still ok.) But keep in mind that a composite index also adds a lot
> of overhead for updates, takes up more room in the index cache, and doesn't
> really add much speed if the extra columns don't have a high selectivity,
> i.e., filter out many unwanted records.

True. However, I suspect with some of our queries, our existing single-
field index only has very low selectivity, which makes stuff like "Most
wanted" and "History" so slow. Not using any composite indexes seems like
a bad idea to me, especially given the fact that some of our queries are
run on huge random-sequence tables.

>> 2) The HANDLER command. HANDLER, which works with both InnoDB and MyISAM,
>> provides low-level access to tables *without locking*. You get reads, but
>> you don't get consistency, which may cause problems when you're dealing
>> with critical, heavily modified data. But it seems perfect for our archive
>> stuff.

> If there are not many updates then this accomplishes next to nothing, except
> that you have made the software more complicated.

HANDLER works almost exactly the same as SELECT from a syntax POV. We have
many updates on the OLD table, and it is still in MyISAM, meaning table-
level locking. So unless we upgrade that particular table to InnoDB (which
Brion seems reluctant to do because of the long downtime), HANDLER may be
worth giving a try.

However, your point regarding complexity is well taken. We could abstract
the HANDLER function in wfQuery using a "consistent read" parameter, by
default being true.

>> 3) Upgrading to MySQL4.

> Actually I was once in favour of that but Lee convinced me that as long as
> the developers of MySQL don't think it is ready for production, we shouldn't
> either. There is only one thing more important than speed and that is
> stability.

They are currently labeling it as a "gamma". I think it might be worth
giving a try, we can always downgrade if it creates problems.

>> 5) Caching our article index. I have mentioned this idea before, I think:
>> We could just keep our entire article index in memory *persistently*
>> (currently the linkcache is filled for each request), which should make
>> link lookup almost instant.

> What makes you think it isn't already?

I have done tests on the link lookup with a local database and it's very
slow with link-heavy pages. This is also what our profiling has shown.
Again, that may have something to do with our index use and we may want to
look into that. Note that I haven't yet benchmarked the new prefill
mechanism.

> I suspect the biggest part of the
> involved tables is in the cache anyway,

I don't trust automatic caching, especially since our CUR table is huge
and it is only a very small subset of it (the titles) which we need in
memory.

> Keeping the software straightforward and
> understandable and for newcomers that also want to help with programming is
> a big priority for any open source project.

The current link caching mechanism is far from easy to understand, it
might just be considerably less efficient than the alternatives.

Regards,

Erik


from_name: Zoe

subject: [WikiEN-l] Challenge to Sheldon Rampton re: global warming (was: DW is still here - time for an IP ban)

body:
Whatever my personal views of the issue may be, your choice of wording as "the oil men who pass for government in your country" certainly shows YOUR agenda.  I hope it's not in the article, which I have yet to read.
Zoe
 tarquin <tarquin at planetunreal.com> wrote:The 84 countries who've signed the Kyoto Protocol seem to think that
global warming is a real issue.

Seems it's largely the oil men who pass for government in your country
who think otherwise. Might they have an agenda?

Poor, Edmund W wrote:

>Hey, speaking of disingenuous answers, how about applying the NPOV to the [[global warming]] article? Are you able to step back from your advocacy and be neutral for a few minutes, and help us make a balanced article there?
>
>One of the best ways to attain neutrality in a contentious article is for a person who believes passionately in one side to focus on making the best case for the OTHER SIDE. If you could do this, it would be a big help.
>
>Ed Poor
>_______________________________________________
>WikiEN-l mailing list
>WikiEN-l at wikipedia.org
>http://www.wikipedia.org/mailman/listinfo/wikien-l
>
>
>

_______________________________________________
WikiEN-l mailing list
WikiEN-l at wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikien-l

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030201/d4ed0920/attachment.htm


subject: [Wikipedia-l] We need more information on the Baghdad Agreed Minutes Rega...

body:
Why?  What purpose does it serve, other than to drive away those of us who are fed up with the wars?
Zoe
 daniwo59 at aol.com wrote:It may not be a popular position, but i really do believe in giving a second (or is it a third) chance. Inevitably, people will be watching the articles and going over them with a finetooth comb anyway. Still, this could be a potentially valuable contribution. If asked to vote, I would say yes. Let Lir, Vera, Adam or whatever contribute, at least on a trial basis.

Danny

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030201/581d8404/attachment.htm


subject: [WikiEN-l] partisan wrangling on wikipedia

body:
Gee, is that aimed at me?  How do you know that what I advocate isn't my own opinon?  You haven't bothered to ask, have you?
Zoe
 Ray Saintonge <saintonge at telus.net> wrote:koyaanisqatsi at nupedia.com wrote:

>When I think of wikipedia, somehow I'm reminded of the [[Milgram
>experiment]]--except the seats are really wired. Currently I would
>not recommend anyone join wikipedia, unless the person knows of some
>obscure Russian filmmaker to write about or some photographic
>technique which calls for dry unemotional writing. Something about
>the culture here is just *wrong*; it calls to people who itch to have
>a buzzer in hand, and those of us lucky enough not to be on the
>receiving end are still uncomfortable watching the spectacle.
>
>Why are you here? Are any of you trying to change another person's
>opinion? If you are, you belong on Usenet, and best of luck.
>
Regretably, you make a good point. I'm sure that Wikepedia too has its
expected 61% of otherwise good people who will always push the button
when told to do it. Sometimes people just want to be told what to do
even while they're voicing support for some kind of democracy. They
become so afraid to offend that they no longer trust their. They're
perfect soldiers -- perfect cannon fodder. When they defend an opinion
it's with the ardour of a my-country-right-or-wrong patriot.

Eclecticology

_______________________________________________
WikiEN-l mailing list
WikiEN-l at wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikien-l

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030201/61ca23f3/attachment.htm


from_name: Magnus Manske

subject:
Spin-off software (was Re: [Wikitech-l] "View user page" edit
 links on anon talk pages)

body:
Erik Moeller wrote:

>No objections - just a few more "if($wgSomeGlobalVar)"s I guess. But
>perhaps you could post a more detailed proposal of what you want to change
>and how.
>
I didn't work the details myself yet - actually, I'm still fighting with
my latest Linux installation ;-)

>Also, I still think that a well-integrated, generalized group
>certification system makes more sense than a separate filter project.
>
We could do both in the same code, then set up both as different
projects, and wait what happens. Nobody expected what happened to
Nupedia and Wikipedia.

Magnus


subject: [WikiEN-l] RE:  partisan wrangling on wikipedia

body:
On Saturday 01 February 2003 01:37 pm, Geoff Burling wrote:
> That is a pessimistic view of Wikipedia in its current state. Accurate,
> from what I've observed of certain articles, but still pessimistic.
>
> Unfortunately, the evaluation of mankind's accumulated knowledge frequently
> results in the same kind of dust-ups we're seeing in Wikipedia. For
> example, Eric Thompson, while undoubtedly the most learned & influential
> scholar of Mayan history & culture in recent times, nonetheless delayed
> the successful translation of Mayan inscriptions for a generation
> because of his own biasses and a tenacious insistence on his own POV.
> For an example outside of the humanities, I am reminded of an attempt by
> one of the leading US medical journals -- I forget if it was the New
> England Journal of Medicine or the Journal of the AMA -- to review the
> lauded discoveries that journal had published a few years prior: after
> a few months they discontinued this series, having discovered
> that far too many of these articles turned out to have been bad science![*]

Excellent point! I was thinking about writing just such an email. In short:
Anybody who believes that is is possible /not/ to have bickering and
wrangling in Wikipedia hasn't spent much time working with large groups of
people in an academic setting (or even in an office working on a project for
that matter).

Different people have different viewpoints and Wikipedia IMO does a very good
job of distilling the POV down to their NPOV elements. But this process takes
a lot of time for highly contentious subjects. It also occasionally requires
us to expel those people who can't work with others - but the same is true in
the real world.

--mav
WikiKarma:
Work on adapting NASA bio information to expand [[Rick D. Husband]]


subject: [Wikipedia-l] Problem with "User Contributions"

body:
For several days now, when I've clicked on "User Contributions" on my user page, Wikipedia has churned for several minutes, and then displayed the browser's "The page cannot be displayed".  I can sometimes Refresh and eventually it comes up, but today, that's been completely unsuccessful.

Zoe

---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030201/296aae22/attachment.htm


subject: [Wikitech-l] Optimizing and tuning

in_reply_to: <8f0MNmPhpVB@erik_moeller>; from erik_moeller@gmx.de on Sat, Feb 01, 2003 at 01:14:00PM +0100

body:
On Sat, Feb 01, 2003 at 01:14:00PM +0100, Erik Moeller wrote:
> > That is correct, and you could be right about this (I don't know what
> > the current database schema looks exactly like, but last time I was
> > involved this was still ok.) But keep in mind that a composite index
> > also adds a lot of overhead for updates, takes up more room in the index
> > cache, and doesn't really add much speed if the extra columns don't have
> > a high selectivity, i.e., filter out many unwanted records.
>
> True. However, I suspect with some of our queries, our existing single-
> field index only has very low selectivity, which makes stuff like "Most
> wanted" and "History" so slow.

Adding composite indexes won't help there. What you need is an extra
redundant table that contains the number of wanted links.

> >> 2) The HANDLER command. HANDLER, which works with both InnoDB and MyISAM,
> >> provides low-level access to tables *without locking*. You get reads, but
> >> you don't get consistency, which may cause problems when you're dealing
> >> with critical, heavily modified data. But it seems perfect for our archive
> >> stuff.
>
> > If there are not many updates then this accomplishes next to nothing, except
> > that you have made the software more complicated.
>
> HANDLER works almost exactly the same as SELECT from a syntax POV.

That's only part of the problem. If anyone wants to mess with this they have
to understand what it does and why. That doesn't go away if you have similar
syntaxes.

> >> 3) Upgrading to MySQL4.
>
> > Actually I was once in favour of that but Lee convinced me that as long as
> > the developers of MySQL don't think it is ready for production, we shouldn't
> > either. There is only one thing more important than speed and that is
> > stability.
>
> They are currently labeling it as a "gamma". I think it might be worth
> giving a try, we can always downgrade if it creates problems.

Not if we start using MySQL4 stuff and the problems only start to appear
after a while. I agree that the risc is very small, but still.

> >> 5) Caching our article index. I have mentioned this idea before, I think:
> >> We could just keep our entire article index in memory *persistently*
> >> (currently the linkcache is filled for each request), which should make
> >> link lookup almost instant.
>
> > What makes you think it isn't already?
>
> I have done tests on the link lookup with a local database and it's very
> slow with link-heavy pages. This is also what our profiling has shown.

Could you be a bit more specific about that?

> > I suspect the biggest part of the involved tables is in the cache
> > anyway,
>
> I don't trust automatic caching, especially since our CUR table is huge
> and it is only a very small subset of it (the titles) which we need in
> memory.

For an existence query it only needs the index, not the table itself. Did
you check if we are doing something silly here so that the database has to
access the table anyway? What does EXPLAIN say here?

-- Jan Hidders

 .---------------------------------------------------------------------.
 | Post-doctoral researcher               e-mail: jan.hidders at ua.ac.be |
 | Dept. Math. & Computer Science         tel: (+32) 3 820 2427        |
 | University of Antwerp, room J1.06      fax: (+32) 3 820 2421        |
 | (UIA) Universiteitsplein 1, B-2610 Wilrijk - Antwerpen   (Belgium)  |
 `---------------------------------------------------------------------'


subject: [Wikipedia-l] Limited client-side caching

body:
In an effort to reduce our traffic by cutting out unintentional reloads
(particularly through using the 'back' and 'forward' buttons in Internet
Explorer), certain accesses to Wikipedia are now marked to allow
browsers to cache them.

Now cacheable are:
- Viewing an article's current version
- Viewing an older version of an article
- Showing an article's history
- Recent changes list

The browser still must check with the server to see if the page has
changed, but if it hasn't the browser's cached version can be shown,
saving a lot of database sorting, wikitext parsing, link checking, and
bandwidth. If it has changed, you get the new version.

I haven't been able to get Mozilla to consistently behave correctly
(probs with the expiry time; it doesn't check for updates), so for
Gecko-based browsers the pages will still be marked as un-cacheable.
This isn't as big a deal anyway, as Mozilla will in any case use cached
pages when traversing the "back" and "forward" buttons; IE's forced
reloads in this situation are the primary target.

(The pages are also marked 'private', so shared proxy caches shouldn't
send one person's logged-in pages to another person.)

If anyone has (new) problems with pages showing old versions when they
shouldn't, please let me know!

So far this is installed only on www.wikipedia.org and
test.wikipedia.org. It'll go on meta and the rest of the languages soon
when I get other things updated this weekend.

-- brion vibber (brion @ pobox.com)


subject: [Wikitech-l] Re: Optimizing and tuning

in_reply_to: <1043894781.1082.814.camel@rdaneel.vibber.org>; from brion@pobox.com on Wed, Jan 29, 2003 at 06:46:22PM -0800

body:
Jan Hidders wrote:
> On Sat, Feb 01, 2003 at 01:14:00PM +0100, Erik Moeller wrote:
> > Jan Hidders wrote:
> > >
> > > I suspect the biggest part of the involved tables is in the cache
> > > anyway,
> >
> > I don't trust automatic caching, especially since our CUR table is huge
> > and it is only a very small subset of it (the titles) which we need in
> > memory.
>
> For an existence query it only needs the index, not the table itself. Did
> you check if we are doing something silly here so that the database has to
> access the table anyway? What does EXPLAIN say here?

Sorry for replying to myself, but I just saw in CVS that the SQL is
something like this:

  SELECT HIGH_PRIORITY cur_id
  FROM cur
  WHERE cur_namespace=" . "{$ns} AND cur_title='" . wfStrencode( $t ) . "'";

but if I look in buildTables.inc we have a separate index for namespace and
title. That should really be a combined index and that holds for everywhere
we do a look-up with namespace + title. Do we have those?

And I'm not sure if we really need the resulting cur_id. If we don't, then
indeed only the index is needed and that would really speed up the query.

-- Jan Hidders

 .---------------------------------------------------------------------.
 | Post-doctoral researcher               e-mail: jan.hidders at ua.ac.be |
 | Dept. Math. & Computer Science         tel: (+32) 3 820 2427        |
 | University of Antwerp, room J1.06      fax: (+32) 3 820 2421        |
 | (UIA) Universiteitsplein 1, B-2610 Wilrijk - Antwerpen   (Belgium)  |
 `---------------------------------------------------------------------'


from_name: koyaanisqatsi at nupedia.com

body:
mav writes:
>Anybody who believes that is is possible /not/ to have bickering and
>wrangling in Wikipedia hasn't spent much time working with large
groups of
>people in an academic setting (or even in an office working on a
project for
>that matter).

I've been here since April 2001.  you judge if that's long enough to
determine whether things are getting better or worse, or staying the
same.  thanks for the personal snub though.  I suppose I had it coming.

>Different people have different viewpoints and Wikipedia IMO does a
very good
>job of distilling the POV down to their NPOV elements. But this
process takes
>a lot of time for highly contentious subjects. It also occasionally
requires
>us to expel those people who can't work with others - but the same is
true in
>the real world.

Perhaps I'm just impatient then.  Certainly the pedia, as of late,
seems to be for some other type of person than me.

kq


subject: [Wikitech-l] Optimizing and tuning

body:
> Adding composite indexes won't help there. What you need is an extra
> redundant table that contains the number of wanted links.

We have a table that contains broken links, which is used in the Most
Wanted query. I have no information about the size of these tables in our
current database, but I suspect that, again, indexes are not properly
used, otherwise the bad performance of this query (which has prompted
Magnus to cache the whole page and Brion to create a "miser" mode in which
it cannot be loaded) is not explainable.

>> HANDLER works almost exactly the same as SELECT from a syntax POV.

> That's only part of the problem. If anyone wants to mess with this they have
> to understand what it does and why. That doesn't go away if you have similar
> syntaxes.

I think your arguments against HANDLER are misguided. We clearly have
situations where we do not nead consistent reads, and in these situations,
HANDLER may be a great help. As I said, we can abstract the functionality
to reduce complexity.

>> They are currently labeling it as a "gamma". I think it might be worth
>> giving a try, we can always downgrade if it creates problems.

> Not if we start using MySQL4 stuff and the problems only start to appear
> after a while. I agree that the risc is very small, but still.

How about using it on meta only? It is reasonably active, but not mission
critical.

>>>> 5) Caching our article index. I have mentioned this idea before, I think:
>>>> We could just keep our entire article index in memory *persistently*
>>>> (currently the linkcache is filled for each request), which should make
>>>> link lookup almost instant.
>>
>>> What makes you think it isn't already?
>>
>> I have done tests on the link lookup with a local database and it's very
>> slow with link-heavy pages. This is also what our profiling has shown.

> Could you be a bit more specific about that?

see
http://www.wikipedia.org/pipermail/wikitech-l/2002-November/001166.html
http://www.wikipedia.org/pipermail/wikitech-l/2003-January/002238.html

Regards,

Erik


body:
On Sat, Feb 01, 2003 at 07:15:29AM -0800, Jonathan Walther wrote:
> On Sat, Feb 01, 2003 at 09:45:18AM -0500, The Cunctator wrote:
> >> I have to rise to Ed's defense.  I have only seen Ed trying to make sure
> >> all sides of the story are represented.  Presenting global warming as a
> >> scientifically proven "fact" is disengenous, dishonest, and unethical.
> >> It is a popular theory, yes.  But it is also a controversial one.  I
> >> have every confidence in Ed's neutrality.
> >>
> >Anthropogenic global warming, by the standard scientific definition of
> >"fact", is a fact.
>
> You didn't read the two URL's I cited, did you.

And you appartently don't know what the standard scientific definition of
fact is.

> And your "fact" is debatable.  Indeed, myself and many others do debate
> it.

Everything is debatable. Wikipedia is not a discussion forum for scientific
discussions. It is an encyclopedia and as such should reflect the current
thinking on issues that is shared by most experts on the subject in the
world. So if you want that global warming is not presented as fact then you
have to convince the others that this is the opinion of a large majority of
the experts. The two URLs you provided are certainly not enough for that.

-- Jan Hidders


body:
On sab, 2003-02-01 at 14:33, Zoe wrote:
> For several days now, when I've clicked on "User Contributions" on my
> user page, Wikipedia has churned for several minutes, and then
> displayed the browser's "The page cannot be displayed".  I can
> sometimes Refresh and eventually it comes up, but today, that's been
> completely unsuccessful.

That's cause you edit too much, Zoe. ;)

Seriously, though, yes. Certain operations that involve checking large
numbers of old page revisions are sometimes excruciatingly slow of late.
This is hitting:

* User contributions
* History of oft-edited pages with hundreds of revisions (Village pump,
mav's talk page, current events, talk:main page, vandalism alerts)
* Diff to last edit on the same. (This involves sorting to find the most
recent edit, and that seems to be holding us up.)

Until this is resolved, I'd like to ask that you _don't_ hit refresh
when one of these is churning away like mad, but rather just let it go.
The first query keeps running for a while, and it's just not going to go
anywhere until it's done (or I or Magnus or someone logs in and kills
the query), and a second request might just make it worse. :(

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030201/0bec908c/attachment.pgp


subject: [Wikitech-l] Optimizing and tuning

in_reply_to: <8f0MQiDSpVB@erik_moeller>; from erik_moeller@gmx.de on Sat, Feb 01, 2003 at 04:44:00PM +0100

body:
On Sat, Feb 01, 2003 at 04:44:00PM +0100, Erik Moeller wrote:
> > Adding composite indexes won't help there. What you need is an extra
> > redundant table that contains the number of wanted links.
>
> We have a table that contains broken links, which is used in the Most
> Wanted query.

I know. I was the one who originally introduced that table. :-)

> I have no information about the size of these tables in our current
> database, but I suspect that, again, indexes are not properly used,
> otherwise the bad performance of this query (which has prompted Magnus to
> cache the whole page and Brion to create a "miser" mode in which it cannot
> be loaded) is not explainable.

I can assure you that the indices are well-defined there and used in the
proper way. Some queries are simply hard to compute and can only be improved
by precomputing stuff in redundant tables.

> >> HANDLER works almost exactly the same as SELECT from a syntax POV.
>
> > That's only part of the problem. If anyone wants to mess with this they
> > have to understand what it does and why. That doesn't go away if you
> > have similar syntaxes.
>
> I think your arguments against HANDLER are misguided. We clearly have
> situations where we do not nead consistent reads, and in these situations,
> HANDLER may be a great help. As I said, we can abstract the functionality
> to reduce complexity.

As I said, syntactically hiding the complexity doesn't make it go away.

> >> They are currently labeling it as a "gamma". I think it might be worth
> >> giving a try, we can always downgrade if it creates problems.
>
> > Not if we start using MySQL4 stuff and the problems only start to appear
> > after a while. I agree that the risc is very small, but still.
>
> How about using it on meta only? It is reasonably active, but not mission
> critical.

Good idea, but I assumed that Brion was going to test it on the test server
anyway.

> >> I have done tests on the link lookup with a local database and it's
> >> very slow with link-heavy pages. This is also what our profiling has
> >> shown.
>
> > Could you be a bit more specific about that?
>
> see
> http://www.wikipedia.org/pipermail/wikitech-l/2002-November/001166.html
> http://www.wikipedia.org/pipermail/wikitech-l/2003-January/002238.html

Ok. I commented already on that in my other mail. Btw. did you see Lee's
original comments in linkcache.doc in /docs on why the caching is done the
way it is done?

-- Jan Hidders

 .---------------------------------------------------------------------.
 | Post-doctoral researcher               e-mail: jan.hidders at ua.ac.be |
 | Dept. Math. & Computer Science         tel: (+32) 3 820 2427        |
 | University of Antwerp, room J1.06      fax: (+32) 3 820 2421        |
 | (UIA) Universiteitsplein 1, B-2610 Wilrijk - Antwerpen   (Belgium)  |
 `---------------------------------------------------------------------'


from_name: Lee Pilich

subject:
[WikiEN-l] Re: Challenge to Sheldon Rampton re: global
  warming

body:
> > You didn't read the two URL's I cited, did you.
>
>And you appartently don't know what the standard scientific definition of
>fact is.
>
> > And your "fact" is debatable.  Indeed, myself and many others do debate
> > it.
<and so on>

OK, why is this debate happening on the mailing list rather than the
appropriate article's talk page? Hacking this out on the list means a lot
of people who couldn't care less about the argument have to endure it,
while people who might be interested in it but aren't on the mailing list
miss out.

lp (camembert)
WikiKarma: expansion of [[Giovanni Battista Pergolesi]]


subject: [Wikitech-l] What to do with Meta?

body:
> Let me repeat:
>  If POV material isn't allowed on meta then where should it go?

Maybe the Scratch: namespace that was suggested for en.wiki would be a
good idea for meta.wiki. Then we would just have to hack a namespace
filter option for recent changes (which would be a good idea in any case).

Regards,

Erik


body:
At 18:33 01/02/2003 +0100, Erik wrote:
> > OK, why is this debate happening on the mailing list rather than the
> > appropriate article's talk page? Hacking this out on the list means a lot
> > of people who couldn't care less about the argument have to endure it,
> > while people who might be interested in it but aren't on the mailing list
> > miss out.
>
>Maybe you should ask Ed why he wrote his "open letter" in the first place?

I don't care why he wrote it or why anybody responded to it, but this
doesn't seem like the best place to carry it on.

lp (camembert)


body:
> OK, why is this debate happening on the mailing list rather than the
> appropriate article's talk page? Hacking this out on the list means a lot
> of people who couldn't care less about the argument have to endure it,
> while people who might be interested in it but aren't on the mailing list
> miss out.

Maybe you should ask Ed why he wrote his "open letter" in the first place?

Regards,

Erik


body:
On Saturday 01 February 2003 04:41 pm, kq wrote:
>mav wrote:
>Anybody who believes that it is possible to /not/ have bickering and
>wrangling in Wikipedia hasn't spent much time working with large
>groups of people in an academic setting (or even in an office working on a
>project for that matter).
>
> I've been here since April 2001.  you judge if that's long enough to
> determine whether things are getting better or worse, or staying the
> same.  thanks for the personal snub though.  I suppose I had it coming.

No! You are reading too much into my words. You never said that it is
possible for us to keep from bickering and wrangling so my above statement
was not directed at you but at Wikipedia skeptics in general who /do/ say
exactly that (and then fault us for not accomplishing this artificial ideal).

As usual I was only thinking about the larger picture and was majorly
insensitive in how I presented myself.

Please except my sincerest apologies for being so stupidly unclear.

--mav

Added more events to [[January 30]] and updated all the year pages and many
other articles linked from that page.


from_name: daniwo59 at aol.com

body:
I've been having that problem too.

Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030201/127fb302/attachment.htm


subject: [Wikitech-l] Optimizing and tuning

in_reply_to: <1044120563.2074.141.camel@rdaneel.vibber.org>; from brion@pobox.com on Sat, Feb 01, 2003 at 09:29:24AM -0800

body:
On Sat, Feb 01, 2003 at 09:29:24AM -0800, Brion Vibber wrote:
>
> Jan has suggested having a summary table that keeps track of the counts,
> so we can access them directly. I'm inclined to agree; we could update
> it on page saves (and deletes and renames and undeletes!) to save the
> bother of the group/count/sort behemoth.

Yes. Every time you update the brokenlinks table you also have to update the
wantedpages table, so that shouldn't be too hard to find in the code.

> Something like:
>
> CREATE TABLE wantedpages (
>   wanted_title varchar(255) binary NOT NULL default '',
>   wanted_count int unsigned NOT NULL default 0,
>   UNIQUE KEY wanted_title,
>   INDEX wanted_count
> );
>
> Index on the count, certainly, to speed the sort for the most wanted
> display. Index on the title should speed picking the right ones on
> updates, right?

Exactly. Btw., shouldn't namespace be in there somehwere or is that still a
part of the title?

> I suspect we can be smarter about how we update links and brokenlinks as
> well; currently we just delete every row pertaining to the page we're
> dealing with and re-insert it.

Probably, because when a page is saved you have to retrieve the "old" broken
links from the DB anyway because there is no other way of knowing them and
you need them to updated the wantedpages table. So you might as well compare
them to the new list of broken links and remove/add only what has changed,
which is usually only a few links anyway.

-- Jan Hidders


from_name: Tom Parmenter

body:
Tried and tried and tried again. Enough is enough.

Tom Parmenter
Ortolan88

|From: Zoe <zoecomnena at yahoo.com>
|Sender: wikipedia-l-admin at wikipedia.org
|Reply-To: wikipedia-l at wikipedia.org
|Date: Sat, 1 Feb 2003 13:33:40 -0800 (PST)
|
|--0-1260886672-1044135220=:41071
|Content-Type: text/plain; charset=us-ascii
|
|
|Why?  What purpose does it serve, other than to drive away those of us who are fed up with the wars?
|Zoe
| daniwo59 at aol.com wrote:It may not be a popular position, but i really do believe in giving a second (or is it a third) chance. Inevitably, people will be watching the articles and going over them with a finetooth comb anyway. Still, this could be a potentially valuable contribution. If asked to vote, I would say yes. Let Lir, Vera, Adam or whatever contribute, at least on a trial basis.
|
|Danny
|
|_______________________________________________
|Wikipedia-l mailing list
|Wikipedia-l at wikipedia.org
|http://www.wikipedia.org/mailman/listinfo/wikipedia-l
|


subject: [WikiEN-l] User:Vera Cruz

body:
I thought that User:Vera Cruz was banned, yet s/he is making edits, and
just made [[Laurel Clark]]. Am I mistaken, and she's not been banned at all?

I don't much care whether she's banned or not, incidentally, but a lot of
other people seem to, and I'm curious as to what's happened here.

lp (camembert)


subject: [Wikitech-l] two small patches to texvc code

body:
On mer, 2003-01-29 at 22:29, Tomasz Wegrzanowski wrote:
> Some minor things got wrong with new version of texvc.
> Here are fixes.
>
> Already installed on test.

Okay, I've put the updates into CVS and installed them on the test and
English wikis so far. Seems to run. :)  Tomasz, please double-check
LanguagePl.php and OutputPage.php to make sure everything got integrated
correctly.

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


subject: [Wikitech-l] Diff links in recentchanges

body:
Fixing an old bug, I went ahead and made the diff links in the "classic"
Recentchanges view include the oldid numbers, so they show specifically
the diff for the edited item. (We get the information provided for us
already in our read of the recentchanges table.)

For extra points, this prevents the slowdown when someone selects the
last diff of a page with many revisions.

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


body:
mav writes:
>No! You are reading too much into my words. You never said that it is
>possible for us to keep from bickering and wrangling so my above
statement
>was not directed at you but at Wikipedia skeptics in general who /do/
say
>exactly that (and then fault us for not accomplishing this artificial
ideal).

Well, my point was that it seems wikipedia could be more collegial.
Some conflict is to be expected, yes, but I rather suspect some people
look forward to it when it comes.  Some people live for it, some
merely tolerate it, some people are bothered by it and avoid it.  I'm
formerly of class 1 (horrible arrogant troll I was 5 years ago),
recently of class 2, moving towards class 3.  I guess this is my
problem, not everyone else's, except I wonder how many people really
_enjoy_ acrimony--fewer than 12 on the 'pedia, I imagine, probably
fewer than six, and I wonder how many of the other several hundred
active contributors truly are put off by it.  Those kind of people
tend to be quieter about it until they've had enough, and then they
leave, with or without explanation.  I think Julie was one of those
people; and losing her was a considerable loss.

>As usual I was only thinking about the larger picture and was majorly
>insensitive in how I presented myself.

I don't know about all that.  And currently I am the champ of sloppy
writing.

>Please except my sincerest apologies for being so stupidly unclear.

That's ok.  I'm sorry for reading it wrong.  :-)  Offense taken,
momentarily, then put back down.

best wishes, I will see you all (except the lurkers) ;-) in a few weeks.

kq


subject: [WikiEN-l] Vera Cruz is up to her old bad habits already

body:
On Sun, Feb 02, 2003 at 06:26:50PM +1100, Tony Wilson wrote:
>Yep - she's marking EVERYTHING as a "minor change" again. The edit war
>lunacies can't be far away. Please, can't anyone DO SOMETHING?
>
>She is supposed to be banned. Twice over. Is "banning" just a word that
>means "go away for a few days"?

Who let him back, and why?  I understand that banned persons have the
opportunity to redeem themselves, and I am all for that. But I would
appreciate it when a banned person is allowed back, if that would be
announced publicly so that there is none of this confusion of "should so
and so be back, or are they trying to get around the rules again?"  Not
being certain that a person has legitimately returned can negatively
affect the persons ability to try and get off to a fresh start.

Jonathan

--
                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw at reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
Url : http://lists.wikimedia.org/pipermail/wikien-l/attachments/20030201/d6f70241/attachment.pgp


from_name: Anthere

subject: [Wikipedia-l] Racialisme

body:
--- Lars Aronsson <lars at aronsson.se> wrote:
> Guillaume Blanchard wrote:
> > And what is the criteria that make a word that
> don't exist
> > officially can be add in an encyclopedie or not ?
>
> This particular part of the problem has a very easy
> solution:
> If there is any doubt about a word, start the
> article by explaining
> how and when the word has been used, for example
>
>   "the leader of the green party Mrs. Xxxx Yyyy has
> often used the
>    word 'biodiversity' in her speeches in
> parliament, and in an often
>    cited article in Le Monde in February 2000.  She
> uses this word to
>    mean ...".

very good advice Lars, thanks

With some luck, the real names of some wikipedians
could appear in wikipedia :-)

> The former is NPOV, since it describes actual facts
> (Mrs X Y used this
> word), whereas the latter is subjective (I want...).
>  The former helps
> people understand what they hear and read in news
> media, and thus has
> a place in an encyclopedia.  Wikipedia is online and
> moves faster
> than L'Academie Francaise.  Perhaps they should be
> reading Wikipedia
> to discover new words.
>
> The opposite problem is words that have fallen out
> of use, that only
> need to be explained to help people understand
> really old texts, such
> as Phlogiston.

Hummmmm.....I don't know that word. It is not in my
dic. Maybe it doesnot exist...anyway, it may belong to
wiktionary more than wikipedia maybe ?

Seriously, phlog and phlox means flame. I would
guess...that's an old type of lighter...or a cannon
filled with oil-enflammed tissue used in middle age
wars...or a mythological dragon...or a politician very
skilled in spiting nasty comments...

right

I don't know

-------------

btw, thanks to all who gave good advices on this issue

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


body:
On dim, 2003-02-02 at 00:32, sannse at delphiforums.com wrote:
> I'm getting completely blank white pages when I use the 'back' or 'forward'
> buttons.  It doesn't happen every time, but most of the time and to all
> pages.  I'm using Internet Explorer 5 and Windows 98.

Okay, try it now. I've made the check more conservative, so it only does
the caching magic on MSIE 5.5, 6, or higher. (5.0 had some other
problems we had to work around as I recall...)

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030202/358193f7/attachment.pgp


subject: [Wikipedia-l] popularity of Eo Wikipedia article on Sweden

body:
On dim, 2003-02-02 at 01:56, Krzysztof P. Jasiutowicz wrote:
> I wonder that we (intl Wikipedias) still have the access counter
> running, while at the English WP it is disabled.

It was disabled mainly for performance reasons -- for every page view,
the database has to be updated with the incremented counter. And lately,
we've been getting A LOT of page views; when the updates get backed up
waiting for a slow save or other query, everything else has to wait. The
English WP gets the vast majority of the traffic, and thus causes the
majority of our problems. ;)

The other wikis still run them because there's little benefit to
disabling their counters -- lower traffic and smaller databases, so the
updates don't get backed up and there's no problem.

However, the counters are so limited that it's not clear just how useful
they are -- they don't distinguish been old and recent traffic; they
don't distinguish between one person loading a page over and over and
ten different people looking at it; they don't distinguish googlebot
from a human. They're probably going to get replaced with a smarter
counter at some point

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20030202/c12da3bf/attachment.pgp


subject: [Wikipedia-l] Jimbo ? Others advices ?

body:
> > It is interesting to note you stated the info on
> > racialism was probably coming from "My Kampf", and

> It was a joke on a talk page. Please don't put my
> sentence outside the
> context

Right Aoineko.
Calling someone "Philippe Kampf" is NO JOKE.
Especially after all the words you have used to depict
him.
Or it means we have a very different definition of
what a joke is. Then we should try an article on
jokes, that might be interesting to give examples

> > There is nothing to justify the insults you use
>
> There is nothing to justify incitement to racism

There is nothing to justify insulting people and
calling them bad names. It only leads to exasparation,
suffering and escalation of violence. We are lucky
Philippe is not replying to your insults with further
insults. What would you do then ? Would you consider
using even nastier insults, or calling the cops ?

For all I know, by "french law" calling someone
"Kampf" or any other of the nice names you have used
is *also* punishable. Check the last legal actions on
these subjects. You might just  as well be liable too.
Think about it.

But apart from legal matters, for which I don't care
much, don't do to others what you would not want
others to do with you. At least that is what the Bible
taught us. I believe that's a valid suggestion.

And a Wikip?dia where grown-up throw such words to
each others faces is definitly not a place I would
recommand to anybody, if only my kids. So please
Aoineko, for the sake of peace, give up the insults.

------

Sur un autre th?me, tes traits 33%

1. Il m'a sembl? que l'essentiel des d?veloppeurs
souhaitaient s'?loigner du html. Donc l'?criture
actuelle n'est pas la bonne, il faut en proposer une
autre.

2. De facon tr?s personnelle, l'?criture html me pose
probl?me car tr?s mal interpr?t? par Op?ra qui
transforme les < et > en garbages caracters assez
fr?quemment. pour cette raison, je ne touche
pratiquement jamais ? la page d'accueil, ou aux pages
contenant des tableaux, car je les d?truis. Si tu
ajoutes partout ce genre de petites barres, je ne
pourrais plus non plus toucher aux articles... c'est
d?finitivement une raison pour mettre pour etre compte
la proposition actuelle :-)

3. Si cette option est ajout?e, elle doit l'?tre sur
toutes les wikip?dia, pas uniquement sur la
francophone. Si elle est rejet?e, elle doit l'?tre
partout. Apr?s, si elle est disponible, elle peut etre
plus ou moins utilis?e sur les diff?rentes wikip?dia,
c'est un autre probl?me

Donc, il faut que plus de personnes soient d'accord.
Je le serais si une autre ?criture (facile et interne
? Wikip?dia) est adopt?e, car cela apporte une
certaine ?l?gance qui a son int?r?t et qui me plait.
Okay ?

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


subject: [Wikipedia-l] Re: Limited client-side caching

body:
On Sunday 02 February 2003 12:56 am, Brion Vibber wrote:
> The browser still must check with the server to see if the page has
> changed, but if it hasn't the browser's cached version can be shown,
> saving a lot of database sorting, wikitext parsing, link checking, and
> bandwidth. If it has changed, you get the new version.

Everything is much faster now and that is great! But one minor annoyance is
that (at least with Konqueror 3.0.3) the New Messages message doesn't seem to
trigger the 'changed page' flag so Konqi dutifully displays the cached
version of a page instead of updating the page to display the new dynamic
content. No biggie though.

BTW, would it be possible to have the top header area be a different HTML
frame so that each frame can be dealt with separately? Then the content of
the page could be cached /server side/ after it is requested by an anon (or a
user with default settings) and served-up for anons and users with default
settings until a change is made to the page. Then the next anon/default user
accessing the page causes all the queries that are needed to render the new
page and then that page version is cached and made available to the next
anon/default user to view... The only thing that would be dynamic for anons
and default users would be the top frame (since it displays their IP/user
name and the 'new messages' link - but that could be cached client side so
long as the display of 'new messages' and changes in login status tells the
browser that that frame has changed). Just some thoughts - do with them as
you see fit.

--mav

WikiKarma
This was a bug report


subject: [Wikitech-l] Re: Limited client-side caching


body:
--- Erik Moeller <erik_moeller at gmx.de> wrote:
> > I agree with Anthere and strongly disagree with
> eliminating personal essays
> > from meta. If POV material isn't allowed on meta
> then where should it go?
> Um .. how about just getting rid of it? Why is it
> within Wikipedia's
> mission to somehow provide storage space for
> personal essays? We're an
> encyclopedia, not a hosting provider.
>
> Taku is correct in that this only makes Meta hard to
> use, especially for
> other people who want to help working on the
> Wikipedia software. While it
> is possible to better organize meta, the Recent
> Changes list is cluttered
> by this stuff. There are literally hundreds of
> entries like this:
>
> ...
> # diff) (hist) . . MN Meta-symbiosis; 15:25 . .
> Saprtacus
> # (diff) (hist) . . M User talk:Saprtacus; 15:43 . .
> Saprtacus
> # (diff) (hist) . . M User talk:Saprtacus; 15:39 . .
> Saprtacus
> # (diff) (hist) . . M User:Saprtacus; 15:38 . .
> Saprtacus
> # (diff) (hist) . . MN Meta-etiology; 15:33 . .
> Saprtacus
> # (diff) (hist) . . M User talk:Saprtacus; 15:31 . .
> Saprtacus
> ...
>
> Now try to find the critical "How Wikipedia can be
> really, really fast"
> development proposal hidden deep within this
> idiosyncratic nonsense.

Meta is not only about software development, so don't
try to restrict his use for that matter.

Besides, you'll have to define what a "personal" essay
is. So not only would we need a consensus for removal
of pages from the meta, but we'll need a consensus
about what a personal essay is, and we'll need to
decide whether each and other page a personal essay
is.

All that to make a couple of articles more visible
(some on software development) or rather some less
visible (those you think are trashing meta).

A simpler way could be to implement a little something
which would allow a user to hide changes made by
another given user.

This was asked on the french wiki btw (not by me). I
think it would for example make sense to hide all the
automatic generation of bots (after it is checked
these are correct). That option sounds to me feasible,
and more desirable than just arbitrarily removing
other people stuff and upsetting them.

(oh crumbs, another feature to reject...)

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


from_name: Lars Aronsson

subject: [Wikipedia-l] Racialisme

body:
Guillaume Blanchard wrote:
> And what is the criteria that make a word that don't exist
> officially can be add in an encyclopedie or not ?

This particular part of the problem has a very easy solution:
If there is any doubt about a word, start the article by explaining
how and when the word has been used, for example

  "the leader of the green party Mrs. Xxxx Yyyy has often used the
   word 'biodiversity' in her speeches in parliament, and in an often
   cited article in Le Monde in February 2000.  She uses this word to
   mean ...".

As you can see, this is very different from

  "I just invented the word 'elxkajels', and I want it to mean ...".

The former is NPOV, since it describes actual facts (Mrs X Y used this
word), whereas the latter is subjective (I want...).  The former helps
people understand what they hear and read in news media, and thus has
a place in an encyclopedia.  Wikipedia is online and moves faster
than L'Academie Francaise.  Perhaps they should be reading Wikipedia
to discover new words.

The opposite problem is words that have fallen out of use, that only
need to be explained to help people understand really old texts, such
as Phlogiston.

--
  Lars Aronsson (lars at aronsson.se)
  Free Wireless Networking - http://elektrosmog.nu/


subject: [Wikipedia-l] Jimbo ? Others advices ?

body:
> P.'s talks are NO JOKE either.

I had understood from what other people said that
Philippe was probably NOT talking. So...do you mean he
is ?

>>don't do to others what you would not want
> > others to do with you. At least that is what the
> Bible
> > taught us. I believe that's a valid suggestion.
> ::demonstration of how this could lead to a
> flamefest,
> ::and that we shoud stay neutral Anthere
> I am an atheist thanks God, this does not apply to
> me then :)
> ::end of demonstration don't catch the flame pliz!

Fair enough
I stay by this assertion though

> You're right, I have thought about the law point of
> view thanks to all
> of you, it is one point to take into account but not
> pertinent in WP
> spirit : I therefore propose that we respect
> epistemological principles
> such as considering Ockham (who was Franciscan
> Anthere) razor for
> instance as a good criterion for accepting (or
> rejecting) a theory. We
> may have to define our epistemological principles
> then, shouldn't we ?

go ahead and put these principles down
we'll see
but science is not the beginning nor the end of
everything.

> > And a Wikip_dia where grown-up throw such words to
> > each others faces is definitly not a place I would
> > recommand to anybody, if only my kids. So please
> > Aoineko, for the sake of peace, give up the
> insults.
> On one hand, insults are unforgiveable, on the other
> hand Aoineko is
> right : there are fights some days and P's behaviour
> is unforgivable
> too, Anthere.  I do rather face conflicts, than
> ignore them.

Sure.

I noticed you put this into action by being yourself
responsible for a *vandalisme* this morning. It was
very fortunate Aoineko noticed it and corrected your
very arbitrary deletion (you were strongly lucky he
labelled that "erreure")

Check out
http://fr.wikipedia.org/w/wiki.phtml?title=P%E9dophilie&diff=26449&oldid=26447

with comment : diffamatoire, non objectif

Clearly, all your recent edits show that you are
yourself very biased, with a strong scientist side,
and a difficult relation with everything that is
related to unusual sexuality. It is important to know,
for us to be very careful of what you do.

Btw, I finally understood why we disagreed on the
racism page

Your comment :
" Le doute sur les sciences, un coup on les invoque,
l'autre on les r?voque. Tu reconnais donc que le
racisme n'est pas une th?orie scientifique, ou quoi?"

This comment shows clearly the need to separate racism
and racialism. For when you are talking of racism, you
are really dealing of racialism. Racism is not a
scientific theory, and all you are talking about
belongs to racialism. When this is clear to you, we
should move the discussion to the racialism
discussion.

> Friendly yours,

yup.

btw 2 : as for the article on cunninlingus, allow me
to be more of a reference than you maybe. I will be
glad if you provide references.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


subject: [Wikitech-l] ReRe: Anthere

body:
--- Pieter Suurmond <pieter at kmt.hku.nl> wrote:
Greetings Pieter,

Personal essays are also serious stuff
Wikipedia is not only built on software
An empty house, even with no holes in the roof, is
still an empty house

Have a good day

> Hi Anthere,
>
> I very much appreciate these 'personal essays'.
> They should be given a proper place (don't remove!).
> They should however be separated from 'development'.
>
> Software-development and maintainance is a very
> serious business, please don't call it 'hacking'
> any longer because Wikipedia is reaching adulthood.
> :-)
> (Grown-up software-developers don't call themselves
>  'hackers': It's all about thinking and
> mathematics!)
>
> Please keep the 'personal essays', but not mixed
> with serious development stuff.
>
> Thanks,
> Pieter Suurmond
>
>
> Anthere wrote:
> >
> > --- Erik Moeller <erik_moeller at gmx.de> wrote:
> > > > I agree with Anthere and strongly disagree
> with
> > > eliminating personal essays
> > > > from meta. If POV material isn't allowed on
> meta
> > > then where should it go?
> > > Um .. how about just getting rid of it? Why is
> it
> > > within Wikipedia's
> > > mission to somehow provide storage space for
> > > personal essays? We're an
> > > encyclopedia, not a hosting provider.
> > >
> > > Taku is correct in that this only makes Meta
> hard to
> > > use, especially for
> > > other people who want to help working on the
> > > Wikipedia software. While it
> > > is possible to better organize meta, the Recent
> > > Changes list is cluttered
> > > by this stuff. There are literally hundreds of
> > > entries like this:
> > >
> > > ...
> > > # diff) (hist) . . MN Meta-symbiosis; 15:25 . .
> > > Saprtacus
> > > # (diff) (hist) . . M User talk:Saprtacus; 15:43
> . .
> > > Saprtacus
> > > # (diff) (hist) . . M User talk:Saprtacus; 15:39
> . .
> > > Saprtacus
> > > # (diff) (hist) . . M User:Saprtacus; 15:38 . .
> > > Saprtacus
> > > # (diff) (hist) . . MN Meta-etiology; 15:33 . .
> > > Saprtacus
> > > # (diff) (hist) . . M User talk:Saprtacus; 15:31
> . .
> > > Saprtacus
> > > ...
> > >
> > > Now try to find the critical "How Wikipedia can
> be
> > > really, really fast"
> > > development proposal hidden deep within this
> > > idiosyncratic nonsense.
> >
> > Meta is not only about software development, so
> don't
> > try to restrict his use for that matter.
> >
> > Besides, you'll have to define what a "personal"
> essay
> > is. So not only would we need a consensus for
> removal
> > of pages from the meta, but we'll need a consensus
> > about what a personal essay is, and we'll need to
> > decide whether each and other page a personal
> essay
> > is.
> >
> > All that to make a couple of articles more visible
> > (some on software development) or rather some less
> > visible (those you think are trashing meta).
> >
> > A simpler way could be to implement a little
> something
> > which would allow a user to hide changes made by
> > another given user.
> >
> > This was asked on the french wiki btw (not by me).
> I
> > think it would for example make sense to hide all
> the
> > automatic generation of bots (after it is checked
> > these are correct). That option sounds to me
> feasible,
> > and more desirable than just arbitrarily removing
> > other people stuff and upsetting them.
> >
> > (oh crumbs, another feature to reject...)
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Mail Plus - Powerful. Affordable. Sign up
> now.
> > http://mailplus.yahoo.com
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l at wikipedia.org
> >
> http://www.wikipedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikipedia.org
> http://www.wikipedia.org/mailman/listinfo/wikitech-l

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


subject: [Wikipedia-l] Jimbo ? Others advices ?

body:
Guillaume Blanchard wrote:

> Secondly it is forbidden by the french law.

Guillaume, in this debate I believe that this partiuclar argument is
*not* helping your case.  You must try better to explain how this is
relevant *in concrete terms* to Wikipedia, or concentrate on other
arguments.  Jimbo does not seem very likely to shut down Wikipedia
after learning on this mailing list that this-or-that is forbidden by
French law, and hearing the same over and over again is just tiresome.
Exactly *who* is going to take Wikipedia to a French court?  And what
sanctions can they use to take down an American website?

I am not a lawyer.  Are you?

--
  Lars Aronsson (lars at aronsson.se)
  tel +46-70-7891609
  Aronsson Datateknik - http://aronsson.se/


from_name: sannse at delphiforums.com

body:
Brion wrote:

> In an effort to reduce our traffic by cutting out unintentional reloads
> (particularly through using the 'back' and 'forward' buttons in Internet
> Explorer), certain accesses to Wikipedia are now marked to allow
> browsers to cache them.
(snip)
> If anyone has (new) problems with pages showing old versions when they
> shouldn't, please let me know!

I'm getting completely blank white pages when I use the 'back' or 'forward'
buttons.  It doesn't happen every time, but most of the time and to all
pages.  I'm using Internet Explorer 5 and Windows 98.

Let me know if you need any other info on this

sannse


body:
Brion wrote:

>Okay, try it now. I've made the check more conservative, so it only does
>the caching magic on MSIE 5.5, 6, or higher. (5.0 had some other
>problems we had to work around as I recall...)

Yep, that seems to have done it.  No problems now.  Guess it's about time I
updated a few things on this machine.

sannse


from_name: Chuck Smith

body:
I'm always suprised when I go to the plej vizitataj
pagxoj (most visited pages) in the Esperanto Wikipedia
and I see:

1. Cxefpagxo (19094-foje)
2. Svedio (3181-foje)
3. Sxekspiro (707-foje)
4. Esperanto-muziko (664-foje)
5. Germanio (604-foje)

Having Shakespeare, Esperanto music and Germany don't
surprise me, but does anyone have a clue why the
article on Sweden is so popular?!  This has been
bugging me for a while now...  :-)

http://eo.wikipedia.org/wiki/Speciala:Popularpages

Mi cxiam surprizigxas kiam mi vizitas la plej
vizitatajn pagxojn en la Vikipedio kaj vidas (la
liston supre).  Sxekspiro, Esperanto-muziko kaj
Germanio ne surprizas min, sed cxu iu scias kial la
artikolo pri Svedio estas tiom populara?!  Cxi tio
"gxenis" min dum iom da tempo nun...  :-)

Thanks / Dankon,
Chuck

=====
Interesting fact:  Google returns more
results for "Esperanto" than for "Catalan"
----------------------------------------
Learn Esperanto! - http://www.lernu.net/
Enciklopedio: http://eo.wikipedia.org/

___________________________________________________
Yahoo! M?viles
Personaliza tu m?vil con tu logo y melod?a favorito
en http://moviles.yahoo.es