from_name: Gerard Meijssen

body:
Ray Saintonge wrote:

> Gerard Meijssen wrote:
>
>> Ray Saintonge wrote:
>>
>>> Jean-Baptiste Soufron wrote:
>>>
>>>>> That's an awful lot to proclaim without a supporting argument.  I'm
>>>>> interested in details of why you think so.
>>>>
>>>>
>>>> Well, my PhD is on the emergence of Law and I am using wikimedia
>>>> and wikipedia as demonstrations for my arguments :)
>>>>
>>>> But you're right, I should write something on it !
>>>
>>>
>>> A simpler response would be to cite the clause in the statute that
>>> says this.  To me a fundamental principal of law is that anything
>>> which is not specifically forbidden is allowed.
>>>
>>> Ec
>>
>>
>> Hoi,
>> It may be a fundamental principal of law. However, I am uncomfortable
>> with it as it leads to all kinds of weasely people do things and
>> argue: "reading the law I can interpretet it in such a way so it
>> should be allowed" while it is totally against what the law is about.
>> It works both ways as this is also used to prevent people from doing
>> things because some people are great in bending the rules.
>
>
> Without fundamental principles the law is meaningless. Reading the law
> in a way that doing something should be allowed is perfectly fine; it
> is neither weasely nor against what the law is about.  Bending rules
> is a part of the normal legal game.  Big companies like Microsoft will
> do whatever they can to have the law work the way they want it to
> work.  If it's right for them it's right for the little guy, and until
> the little guy learns that he will forever be a loser.  The principle
> as I expressed it does not prevent people from doing anything.  If
> something is not mentioned in the law then doing it is not a violation
> of the law.  The converse principle, that what is not specifically
> allowed is forbidden, would lead to the absurdity that any kind of
> innovation is illegal.
>
>> When it comes to our projects, it must be clear that they have their
>> rules, they invoke an image of what they are to mean.
>
>
> The fewer rules the better.  To me an image or vision of what the
> project is about determines what rules are necessary.
>
>> When the language is deemed to be unclear and that is used as an
>> excuse to do what is manifestly against the spirit of our projects, I
>> would not excuse this.
>
>
> Who does the deeming?  If the rules are contrary to the spirit of the
> project I would change the rules.
>
>> The guiding principle of what we do is, we write an encyclopedia, a
>> dictionary, news, training material whatever that is free[,] NPOV and
>> with we do this with respect for our fellow editors.
>
>
> There's nothing wrong with this, but then it has nothing to do with
> the topic.
>
>> We are not a debating club.
>
>
> Who said that we are?
>
>> We have people active as member of our community in practically all
>> legal entities of this world and therefore there is not only one law
>> and one law's principles that we have to take into account.
>
>
> So a balance is required, and this only proves my point.  If something
> is clearly allowed in one country, but requires a slight "bending" of
> the rules in another country we go ahead and bend those rules.  This
> is not the same as an outright violation of the rules.  We do not need
> to strive for the lowest common legal denominator.  If we did that we
> would be bowing to the whims of a government like the one in China
> which might shut the project down for anything that it felt was an
> insult to their government.
>
>> Our rules are different from project to project, it is the spirit of
>> the Wikimedia Foundation that binds us all. It must be clear, that
>> rules within a project that are against the spirit of the WMF are not
>> acceptable, neither are practices that violate what the WMF stands for.
>
>
> The separate rules of different projects are not an issue here.
>
> Ec

Hoi,
Commenting on each line in isolation, you have lost what is meant. If we
were a debating club you would have scored a point but as we are not, it
is a pity. You lose sight of the fact that I wrote that I and many with
me, are disgusted by the way the interpretation of the law in order to
make a position "acceptable". It being a practise held by some does not
make this any less true. This was intended as an introduction to what
followed. As you may have missed this and then continue commenting line
by line I miss the added value of what you try to say. You come to a
conclusion that baffles me; as you think it important to talk about
principles of law. I concluded with stating a principle; that the spirit
of the WMF charter binds us all, a principle that in my opinion should
rule all projects and as such is an issue. It is, as I bring it to the
attention of us all.

Thanks,
    Gerard


list: wikitech-l

source: pipermail-mbox

from_name: Lightning

subject: [Wikitech-l] Parser (was Re: Longterm hosting strategy)

body:
On May 9, 2005, at 10:47 AM, Tim Starling wrote:

>
> One important thing to note is that the parser is a performance
> problem,
> not a scalability problem. We really can throw more hardware at it,
> and
> that will fix it quite nicely. In my opinion, our biggest performance
> problem at the moment is not the parser, it's replication lag and
> database load balancing. There's lots of work that has to be done
> there.
>

Please excuse my ignorance, but why havn't different languages been
split up amongst different database servers?
let me explain what I mean in case that wasn't clear.

Lets say you have 2 Master database servers (for simplicity of
explanation) which replicate to 9 slaves which in turn answer to the
apaches. the apaches are not tied to any database cluster (these were
just split for a ~500k article threshold per cluster, once again just
for simplicity)

                |-- S1.1 |
M1 - En |-- S1.2 |  APACHES
                |-- S1.3 |

                                     |-- S2.1 |
M2 -De, Ja, fr, sv, pl |-- S2.2 |  APACHES
                                     |-- S2.3 |

This allows the Apaches to whore themselves around to whichever
cluster needs them at the moment. Ideally we could do a small traffic
study on the peak hours of each wikipedia and try to pair them off in
such a way that their peak hours miss each other allowing us to
maintain a relatively constant load o the servers (as one peak is
falling another one is rising). Somehow i feel that this would reduce
the loss from replication. Additionally, if there is data that is
shared amongst all wikipedias it could either be set aside in a
separate global cluster, or (is this even possible?) replicated to
all master servers.

What this would do is basically drastically reduce the amount of
replication data flowing from masters to servers, since we all know
that as the overhead of replication grows adding additional slaves
adds less and less additional capacity since most of the time the
slaves are just catching up on what happened on the master.

Now, I have not formally studied db design in school, but this seems
like a reasonable suggestion. Of course i am sure you guys thought
about this before and there is some reason it hasn't been mentioned.
What i would like to know is, if this has been proposed before, what
are the technical obstacles to implementing something like this?

Lightning


list: wikien-l

from_name: Richard Rabinowitz

subject: [WikiEN-l] Abuse of blocking privileges

body:
No offense, but I thought this was a 3RR rule - 3 reverts and revisions
on a page. Since when did it go to 5 reverts/24 h?

On Sun, 8 May 2005, Leif Knutsen wrote:

> User:Jtdirl blocked me (Leifern) for allegedly violating the 5 reverts in 24 hour rule.  This is both unreasonable and an abuse of his admin privileges, for the following reasons:
> - There are actually 4 reverts in about 4 hours
> - The reversions were of deletions of graphs - since it's simply not possible to reword images, I had little option besides reverting the deletions
> - The person who kept deleting the graphs did very little to justify them besides saying that they were irrelevant
> - My adversary (Geni, also an admin) reverted three times, but this apparently didn't bother Jtdirl
> - Jtdirl has an axe to grind - we had an editing dispute that he lost about heirs apparent - I can't help but think this is a vindictive act.
> - Jtdirl gave no warning, made no effort to mediate, simply went ahead and blocked
>
> I don't know what the remedy for this is, but I would propose that both Jtdirl and Geni lose their admin privileges.  If I am not unblocked immediately, I am happy to find another hobby.  I believe my contributions speak for themselves - that would be a great loss for the WP community.
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: Brion Vibber

subject: [Wikitech-l] Longterm software strategy

body:
There are a couple possibilities here. One is to rewrite MediaWiki in
some other language entirely, say Python or C# or whathaveyou.

The other is to keep refactoring the PHP codebase (and it's been much
changed since you left it, Lee) and, optionally, rewrite particular
hotspots in another language.

A possible middle road is to rewrite the core wiki engine to a separate
daemon, and adapt the existing PHP user interface to call into it for
much of the backend work that actually touches data.

The disadvantages of a big rewrite are the disadvantages that all
rewrites carry: a long lead time, getting behind in the game as we lose
useful code and break things again that had been solved, not to mention
introducing brand new exciting bugs. Even the phase 3 rewrite, which was
helpful in many areas, broke a lot of features, reintroduced previously
solved bugs, and set back localization work by many months.

Possible advantages of a complete or core rewrite include performance
enhancements (a JITed or precompiled language could perform better on
some tasks than bytecode-interpreted PHP) and a change in server
architecture.

In particular, PHP tends to impose an architecture where each request is
served by an entirely new script invocation: you have to build any
information up from scratch on each hit, and sharing things like
localization tables between invocations is kind of hard. In another
language it might be easier to run MediaWiki as a standlone server,
which can keep shared data in memory and use it transparently from each
thread.

On the other hand, it's not clear that that's the biggest burden, and we
would still have to synchronize changes in cached data between multiple
servers. Even within PHP we could probably make better use of local
shared memory caches if necessary.

Parsing and rendering speed, as Tim has said, really *is* something we
can throw hardware at. A faster rewritten or plug-in parser might let us
do more with the same hardware, but scaling it is straightforward either
way.

Our biggest, nastiest burden is with internal communications: the
database changes too much. We have to wait on things getting sent,
received, applied, and copied around, and lagging databases send
everything into the toilet fast.

We ask the database too often for information that hasn't changed. We
make a lot of roundtrips, making it hard to make efficient use of
remotely hosted web servers. We make huge writes that produce huge lag
in the replication updates, and then we talk to the master too much
because that lagging replication breaks basic things like page views in
annoying ways.

The new schema is designed to help with these things by minimizing what
has to get written to the database. (We still need to fix up the links
tables to really do this right.) A separate cache-purging daemon could
further help in dealing with things like template invalidation in a
consistent way in the background. Better distinguishing between requests
that need to be absolutely current and requests where it's ok to load a
page that's 30 seconds out of date could make much better use of the
slave servers.

As for the code architecture within MediaWiki itself: originally it was
really really hackish, with lots of cut-n-pasted code and SQL queries
embedded in the middle of HTML output generation. Over time we've been
refactoring things bit by bit to a cleaner interface where backend code
is centralized and consistent, and frontend code can concentrate on UI.
This isn't fully done, but it's still proceeding.

If there's a really strong reason for a rewrite, then we should start
planning a (cleanly implemented, *compatible*, complete) rewrite, making
use of the existing parser tests and other tests in existence and yet to
be written to make sure it'll really be able to take over. If we do, we
should probably target the end of this year or early next year for
taking it live. (No need to rush though; if we're going to rewrite, the
point is to plan ahead and do it right.)

I'm not totally convinced that there is a really strong reason, though.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20050509/d46fb2b3/attachment.pgp>


list: foundation-l

from_name: Ray Saintonge

subject: [Foundation-l] General copyright policy

body:
Yann Forget wrote:

>Hi,
>
>Following the discussion about stamp copyright status on Commons (and many
>other discussions elsewhere), I thing we need better guidelines for works
>without unknown or unreachable author(s). This issue keeps coming back every
>now and then, takes our time and fustrates users because no clear solution is
>in sight.
>
>So I think we should define a general policy about these works without getting
>paranoid about it. They are numerous works whom the author is not known or
>can't ever be reached. This affects all projects, but especially Commons and
>Wikisource. This concerns only "minor" works. If the work is famous, then the
>copyright owner is known, so the question doesn't arise.
>
"Famous" and "minor" are not opposites.  There are plenty of major works
that aren't famous at all.

>I will take examples to show what kind works I am talking about. According to
>people I had on the phone from the French Postage Stamp Museum (Mus?e de la
>Poste), the copyright for French postage stamps belongs to the drawer and the
>engraver. So according to them, we have to inquire about each drawer and
>engraver for these stamps. They are hundreds of unknown artists for French
>stamps only and this is obviously not a workable solution.
>
I think that stamps are a special case.  It doesn't seem right that you
would need to deal with the designer for every stamp just to publish a
picture of the stamp.  Using such pictures in an encyclopedia is a great
example of fair use.  I checked the copyright notice of an Yvert
catalogue, and there was no mention there whatever of the copyrights on
individual stamps, nor even is there a mention of who designed the
stamps.  A similar situation persists with Scott, Gibbons and Michel.  I
find it hard to believe that any of these publications would be running
around contacting every designer for permission to reproduce his stamp.
Surely some designers would object but we see no holes in what the
catalogues list.  These publishers have too much invested in their
catalogues to be playing copyright games.  We only need to know what
rules they are following.

>See these stamps from 1917 to 1936:
>http://fr.wikipedia.org/wiki/Image:Jeux_Olympiques_1924.jpg
>http://fr.wikipedia.org/wiki/Image:PA_Marseille_rouge.jpg
>http://fr.wikipedia.org/wiki/Image:PA_Paris_violet.jpg
>http://fr.wikipedia.org/wiki/Image:Orphelins_5plus5.jpg
>This is not even the worst case, the name of the author is readable.
>I tried to find more about them without success.
>Then there are many others where the name of the author is not even known.
>
Most of this may be easier to find than you think.  Specialized books
about the stamps of a country are quite good about this subject.  I have
an obscenely large personal philatelic library, but I can't say for now
whether I have the kind of material that you seek for France.  A lot of
it is in periodicals for which I have no index.

>As a workable solution, I propose something like: If the drawer and the
>engraver are unknown or unreachable, and the work is more than X years old
>(70 ? 50 ?), this is similar to anonymous work, so we can publish it. So we
>still have to decide what are the criterias for considering the copyright
>owners unreachable or unknown, but I think an agreement could be reached
>about this.
>
Stamps aside, a policy of this sort would be good, but we still have
people who believe in strict interpretations of the law no matter how
foolish the result.  I'm looking forward to the US Copyright Office
report on orphan works.  That would fit nicely with this.

Ec


list: wikimedia-l

subject: [Foundation-l] General copyright policy


from_name: Timwi

subject: [Wikitech-l] Re: Longterm hosting strategy

body:
Gerard Meijssen wrote:
>
> I also do not understand your preoccupation with data centres in the
> USA. We are an international organisation. Our customers are all over
> this earth.

I do not understand everybody's preoccupation with data centres around
the world. Our "customers" are exclusively Internet users, and the
Internet is global. That servers are faster when they are geographically
closer is a wide-spread myth.

Timwi


body:
Jens Frank wrote:
> On Fri, May 06, 2005 at 10:55:30PM +0100, Timwi wrote:
>
>>I see that the overwhelming majority of people here think that splitting
>>different language wikis away from each other is a good idea?
>
> The idea of splitting is to have the master DB for wikis in different
> data centers. They would still replicate their content to the other
> data centers.
> All locations would have a slave copy of all the other languages.

I see. That makes more sense, frankly.

>>I guess I can kiss my vision of a unified cross-language watchlist
>>good-bye then...
>
> Since the data will be available in all datacenters, this should still
> be possible in theory.

Whatever became of my age-old idea of adding a "language" column to
cur/old (now page/revision) and having all data from all languages form
one (virtual) database? That would certainly make a cross-language
watchlist way easier to implement.

> Smaller latency, higher redundancy. Do you remember the hurricane that
> nearly hit Tampa? The power outage in the Tampa datacenter? The
> switch failure?

As already mentioned, the latency is negligible (and indeed between
Europe and North America there is often no more latency than
intra-continentally). As for catastrophe preemption, I figured if
LiveJournal -- a commercial business -- isn't doing it, it can't be
*that* much of a risk. Of course I remember those outages, including
LiveJournal's, but we never really lost any substantial amount of data.
The hurricane wouldn't have caused any more trouble than us having to
rewind to the last backup (which a lot of people world-wide had
downloaded, as far as I understood it).

Timwi


body:
Lars Aronsson wrote:
> Austin Hair wrote:
>
>>When I suggested a state-machine-based parser, people laughed.  I
>>guess history counts for something, after all.
>
> Come on, stupid, this is free software.  Writing running code is
> everything, making suggestions is nothing.  People laugh at
> anybody who writes suggestions instead of code.

Calling people "stupid" is not helping your credibility.

People laughed at me when I offered to rewrite the software in Perl. I
abandoned it, largely because of this unwelcoming disapprovement of the
effort.

You say that coding is everything, but you are clearly not seeing that
people are not likely to code something unless they have reason to
believe that the outcome will be welcome. Throwing suggestions about and
discussing them helps everybody form a picture of what is most likely to
spark enthusiasm in the community, and hence, what is most worth coding.

Timwi


subject: [Foundation-l] A medical glossary

body:
Hoi,
I have spoken today with the people from www.ziekenhuis.nl
(hospital.nl)  they have a great glossary with words that are important
for people who have to go to a hospital. They give the Dutch and the
English words with a description in Dutch. I will enter these words in
the Dutch Wiktionary, I will add the pronunciation of these words and I
will mark them as the category "ziekenhuis".

The aim will be to add translations and descriptions in all languages.
This will make this resource much more important, just knowing the
translations enables much better communication between a patient and the
foreign hospital, so many people end up in hospital not being able to
communicate what their condition is, that this would make an important
resource. When we have the Ultimate Wiktionary on line, added
translations will be instantly available never mind what language you
select in your user interface.

As you may know, we already have permission to use the EU thesaurus on
Health. This will be uploaded once the Ultimate Wiktionary is on line :)

Thanks,
    GerardM


subject: [Foundation-l] A medical glossary


list: wiktionary-l

subject: [Wiktionary-l] A medical glossary


from_name: Neil Harris

body:
Timwi wrote:

> Gerard Meijssen wrote:
>
>>
>> I also do not understand your preoccupation with data centres in the
>> USA. We are an international organisation. Our customers are all over
>> this earth.
>
>
> I do not understand everybody's preoccupation with data centres around
> the world. Our "customers" are exclusively Internet users, and the
> Internet is global. That servers are faster when they are
> geographically closer is a wide-spread myth.
>
> Timwi

Let me help you understand. Your argument does not take into account how
the real Internet works.

The individual servers certainly run at the same speed wherever they are
in the world, but the service does not, because the Internet is not a
free, perfectly reliable, zero-delay network with zero packet loss and
infinite bandwidth.

Consider the effects on TCP dynamics of:
* increased round-trip delays and timing jitter from long paths
* the increased probability of congestion in long paths, rather than
short ones
* the increased probability of having non-congestion-related packet loss
on a long link, compared to a short one

Now also consider:
* the costs of local vs. global transit, given a limited budget
* the likelihood of being offered these for free by donors, given their
relative costs
* the relative costs of transit vs. peering, and opportunities for flow
balancing
and hence the likelihood of having more non-overbooked high-quality
connectivity to more places available at a given price, which in turn
will make the service more resilient against, for example, DDOS attacks.

In particular, you should consider
* the remarkably high performance boost Wikimedia obtained from adding
the Paris cluster, of a mere three machines.
* why most of the root servers are actually globally distributed clusters,
* why Google distribute their servers globally
* and why Akamai and other distributed hosting outfits continue to be
able to sell their services, rather than their customers maintaining a
single big cluster.

Oh, and finally, the killer arguments: the decreased probability of
routing instability and connectivity problems, due to a smaller average
number of forwarding and AS hops, and the removal of a single point of
failure in the event of a data centre disaster.

-- Neil


from_name: Nga Cao

subject: [Foundation-l] Open Publish 2005 Conference | Sydney, Australia

body:
OPEN PUBLISH 2005
5th Annual Conference for Standards in Publishing
27th - 29th July 2005 | Sydney, Australia
http://www.openpublish.com.au

To Whom It May Concern,

I have taken the liberty of sending this email as we would like to
cordially extend
an invitation to the Wikimedia Foundation to participate at the Open
Publish 2005
conference in Sydney, Australia.

Allette Systems (Australia), in conjunction with IDEAlliance (USA) runs
the Asia
Pacific region's annual Open Publish (www.openpublish.com.au) conference
for
people working with standards in traditional, electronic and digital media.

We note that the Foundation is an international non-profit organisation
dedicated
to encouraging the growth, development and distribution of free
multilingual content.
Would the Foundation have any contributors in Australia who may be
interested in
speaking about open content at Open Publish 2005? The session could
either be
conceptual or technical.

Please feel free to contact me should you have any queries or would like
to discuss
this further.

Thank you for your time and I look forward to hearing back from you soon.

-----------------------------------------------------------------
Warmest Regards
Nga Cao
Conference Manager
Open Publish 2005
Ph: +61 2 9660 8866 | F: +61 2 9660 8869
L2/73 Union St, Pyrmont, NSW, Australia 2009
www at allette.com.au | www.openpublish.com.au


from_name: Skyring

subject: [WikiEN-l] Abuse of your services

body:
On 5/9/05, Ray Saintonge <saintonge at telus.net> wrote:
>
> I have never used Usenet as a source of information, and, given the
> controversy that it engenders, I would only do so with extreme caution.
> I would make no absolute rule against using it, but a critical reader
> needs to be aware that its use as a reference will taint the credibility
> of the material.  The value of an article depends on the combined
> credibility of its sources and integrity of its contributors.

UseNet is a great source of facts for UseNet-related information.
Other editors have described using it to test the period of use of
words, phrases, abbreviations and memes. It is a good source for
certain types of information so long as used wisely and selectively.

But using it as a checkable source for general knowledge - the sort of
material one would generally expect to find in an encyclopaedia -
well, I think you've hit the nail on the head with your remarks above.

Having said that, I note that Wikipedia is not as authoritative a
source as we would like. Editors all too often post material that
belongs in the realm of "community myth" rather than "checkable fact".
Just like UseNet.

--
Peter in Canberra


from_name: Georg Chytil

subject: [Wikitech-l] RE: Longterm hosting strategy [warning tome]

body:
While this was generally true in the past, your mileage will vary nowadays
: the costs for hardware and operations are
significant as compared to transit costs, the benefactor has no
real/immediate monetary benefit from hosting a wiki site IMHO.

Plus - you need to be in the Gigabit range to convince a tier 1 provider of
establishing peering(s) with you.

                                                                         #g

At 21:18 06.05.2005, Neil Harris wrote:
[...]
>You might also want to consider that Wikipedia is, on balance, a large net
>source of network traffic, and that peering agreements make most sense for
>networks which have balanced traffic in and out (and, for the same reason,
>transit gets cheaper for balanced flows, even if you cannot negotiate
>settlement-free peering). Thus, network providers with net inflows may
>well be able to make substantial cost _savings_ by giving Wikipedia free
>bandwidth, power and rackspace.
>
>Wikipedia is rapidly becoming big enough to become a player in the peering
>game, or at least should be aware of its advantage to others in doing
>so.  I presume this has not escaped the attention of some of our potential
>benefactors...
>
>-- Neil
>
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l


from_name: Sabine Cretella

subject: [Wiktionary-l] A medical glossary

body:
Just an additional note :-) remembering that time ago people told me
that they could not add things to the Italian wiktionary because they
did not speak Italian and therefore could not use the Italian wiktionary
as the UI is in Italian.

Please remember that you can modify the language of the user interface
as soon as you are logged in, so you will have no problems navigating
the witkonary and you can easily add translations. So we are going to
have another quite extensive glossary - this is indeed great :-)

Thanks Gerard!

Ciao, Sabine

Gerard Meijssen wrote:

> Hoi,
> I have spoken today with the people from www.ziekenhuis.nl
> (hospital.nl)  they have a great glossary with words that are
> important for people who have to go to a hospital. They give the Dutch
> and the English words with a description in Dutch. I will enter these
> words in the Dutch Wiktionary, I will add the pronunciation of these
> words and I will mark them as the category "ziekenhuis".
>
> The aim will be to add translations and descriptions in all languages.
> This will make this resource much more important, just knowing the
> translations enables much better communication between a patient and
> the foreign hospital, so many people end up in hospital not being able
> to communicate what their condition is, that this would make an
> important resource. When we have the Ultimate Wiktionary on line,
> added translations will be instantly available never mind what
> language you select in your user interface.
>
> As you may know, we already have permission to use the EU thesaurus on
> Health. This will be uploaded once the Ultimate Wiktionary is on line :)
>
> Thanks,
>    GerardM


body:
At 21:18 06.05.2005, Neil Harris wrote:
[...]

> You might also want to consider that Wikipedia is, on balance, a large
> net source of network traffic, and that peering agreements make most
> sense for networks which have balanced traffic in and out (and, for
> the same reason, transit gets cheaper for balanced flows, even if you
> cannot negotiate settlement-free peering). Thus, network providers
> with net inflows may well be able to make substantial cost _savings_
> by giving Wikipedia free bandwidth, power and rackspace.
>
> Wikipedia is rapidly becoming big enough to become a player in the
> peering game, or at least should be aware of its advantage to others
> in doing so.  I presume this has not escaped the attention of some of
> our potential benefactors...
>
> -- Neil

Gerard Meijssen wrote:

> Georg Chytil wrote:
>
>>
>> While this was generally true in the past, your mileage will vary
>> nowadays : the costs for hardware and operations are
>> significant as compared to transit costs, the benefactor has no
>> real/immediate monetary benefit from hosting a wiki site IMHO.
>>
>> Plus - you need to be in the Gigabit range to convince a tier 1
>> provider of establishing peering(s) with you.
>>
> Hoi,
> The Dutch and the Belgian organisations are both in the Gigabit range.
> Yahoo and this other "mystery" organisation are in that bracket as well.
> Thanks,
>    GerardM
>
>>
>> #g
>>
>>
>
Indeed. Consider the rate at which Wikipedia is growing, and it looks
likely that it will have flows in the multi-Gigabits range soon. At that
point, the logic of peering tips over the other way. Remember that
peering isn't a magic alternative to paying for transit bandwidth:
no-one will peer with you unless it is in their economic interest.
However, Tier1s have a strong economic incentive to peer with other
high-flow networks at points where both traffic and economic incentives
are balanced. Otherwise, they are just wasting money on unnecessarily
hauling traffic over long distances on their backbone networks, at great
expense to themselves.

-- Neil


body:
Georg Chytil wrote:

>
> While this was generally true in the past, your mileage will vary
> nowadays : the costs for hardware and operations are
> significant as compared to transit costs, the benefactor has no
> real/immediate monetary benefit from hosting a wiki site IMHO.
>
> Plus - you need to be in the Gigabit range to convince a tier 1
> provider of establishing peering(s) with you.
>
Hoi,
The Dutch and the Belgian organisations are both in the Gigabit range.
Yahoo and this other "mystery" organisation are in that bracket as well.
Thanks,
    GerardM

>
> #g
>
> At 21:18 06.05.2005, Neil Harris wrote:
> [...]
>
>> You might also want to consider that Wikipedia is, on balance, a
>> large net source of network traffic, and that peering agreements make
>> most sense for networks which have balanced traffic in and out (and,
>> for the same reason, transit gets cheaper for balanced flows, even if
>> you cannot negotiate settlement-free peering). Thus, network
>> providers with net inflows may well be able to make substantial cost
>> _savings_ by giving Wikipedia free bandwidth, power and rackspace.
>>
>> Wikipedia is rapidly becoming big enough to become a player in the
>> peering game, or at least should be aware of its advantage to others
>> in doing so.  I presume this has not escaped the attention of some of
>> our potential benefactors...
>>
>> -- Neil
>


subject: [WikiEN-l] Re: Abuse of blocking privileges

body:
Leif Knutsen wrote:
>
> If I am not unblocked immediately, I am happy to find another hobby.
> I believe my contributions speak for themselves - that would be a
> great loss for the WP community.

And again. Why do newbies keep posting this? How many people actually
fall for this? How many people actually read this and go "OMG we're
gonna lose a valuable contributor! Must unblock quick!!!"?


body:
Timwi wrote:

>
> As already mentioned, the latency is negligible (and indeed between
> Europe and North America there is often no more latency than
> intra-continentally). As for catastrophe preemption, I figured if
> LiveJournal -- a commercial business -- isn't doing it, it can't be
> *that* much of a risk. Of course I remember those outages, including
> LiveJournal's, but we never really lost any substantial amount of
> data. The hurricane wouldn't have caused any more trouble than us
> having to rewind to the last backup (which a lot of people world-wide
> had downloaded, as far as I understood it).
>
> Timwi
>
>
Western Europe is relatively small with a high population density, and
has *very* good ping times, typically order of 20 to 30 ms, including
things like ADSL interleave. Here are some actual measured figures for
comparison:

 From London to the Paris cluster:

   64 bytes from chloe.wikimedia.org (212.85.150.132): icmp_seq=3 ttl=53
time=28.4 ms (consumer ADSL)
   64 bytes from ennael.wikimedia.org (212.85.150.131): icmp_seq=3
ttl=54time=10.8 ms (Ethernet connection at ISP PoP)

Compare with London to Florida ping times:

   64 bytes from www05.wikimedia.org (207.142.131.247): icmp_seq=1
ttl=49time=121 ms (ADSL)
   64 bytes from www09.wikimedia.org (207.142.131.204): icmp_seq=5
ttl=54time=105 ms (Ethernet)

Now, if a connection was being limited by TCP startup alone, this means
that data would be delivered somewhere between four and ten times
faster, and in particular that page-rendering would be able to start
four to ten times as quickly. In practice, this is not the sole factor
involved, so observed gains will not be as great as this, but they will
certainly be very noticeable by users.

-- Neil


subject: [Wikitech-l] Longterm software strategy

body:
David A. Desrosiers wrote:
>>The other is to keep refactoring the PHP codebase (and it's been
>>much changed since you left it, Lee) and, optionally, rewrite
>>particular hotspots in another language.
>
> 	The downside of this are for people like myself who run an
> external (though not public) version of mediawiki exclusively for use
> in taking parts of it to convert to other formats (in my case, mobile
> and handheld formats). If you change the core language mediawiki is
> driven by, you further burdon external contributors and supporters of
> mediawiki as a whole.
>
> 	..unless you're talking about a rewrite _exclusively_ for use
> on the Wikipedia/etc. servers, and not for the main SF.net project as
> distributed to the community. I suspect you're not talking about this
> approach because that means maintaining two separate (and gradually
> diverging) codebases.

MediaWiki is primarily targeted at Wikipedia and Wikimedia's other
projects (and other similar large-scale sites with people running their
own servers), secondarily at people running local instances to work with
data from our sites, and only incidentally at anyone else.

If to serve our primary target users we have to do something that cuts
out the guy running in a hyper-limited cheap hosting account, sorry but
we may have to do that. Someone running their own installation on their
own box should always be able to obtain the necessary tools, however;
we're committed to always being able to run on a pure free software stack.

The old 'pure PHP' MediaWiki would continue to exist even if we go in a
different direction, and it could be maintained separately for that user
segment if there's interest.

>>In particular, PHP tends to impose an architecture where each
>>request is served by an entirely new script invocation: you have to
>>build any information up from scratch on each hit, and sharing
>>things like localization tables between invocations is kind of hard.
>
>
> 	(Below comments are paraphrased from a conversation I just had
> about an hour ago with Rasmus Lerdorf):
>
> 	Isn't this exactly what ICU[1] was developed to solve? ICU
> 	automatically sticks requests in shared memory in order to
> 	optimize itself across different processes on the same server.

I was primarily thinking of the localized user interface messages there,
but yes the Unicode normalization tables also need to be loaded when
they're needed (though just from source, as they're not user-editable!)

I'm not entirely sure what you're getting at, but we do have an
experimental PHP extension for using ICU to do Unicode normalization. It
needs some more thorough testing before we take it live on our own
servers, though. (When I last tried it it failed completely, returning
empty strings for everything. This may have been an ICU library version
mismatch, I haven't had a chance to fiddle with it again.)

> 	To be truly scalable, nothing should prevent subsequent
> 	requests to be handled by different physical web servers.

Subsequent requests are virtually always handled by different physical
web servers, and we would always expect this to be so. Server-local
retained data thus either needs to be for things that don't change (such
as Unicode normalization tables!) or things that can easily be updated
when necessary (such as caches of the localized UI messages).

Otherwise we have and use the cluster-wide memcached cloud; this
involves some network latency and serialization/deserialization.

> 	And no, it is not hard to use shared memory from PHP.

PHP has a shared memory extension, but IIRC it basically entails copying
a binary string into and out of a shared memory segment, and uses
serializing/deserializing to store arrays and objects. It works, sure,
but if we're _trying_ to avoid constantly copying around large chunks of
data that's only a limited help over what we're already doing.

Compare this with a multithreaded Java or C# app which can simply refer
to the live object or array in memory, in a synchronization block if
necessary.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20050509/6c80ca7d/attachment.pgp>


from_name: Walter Vermeir

subject: [Wikitech-l] request for block of website

body:
http://encyclopedie.izynews.be/fr/lexw.aspx?doc=Special%3aRecentchanges

http://lexikon.izynews.de/de/dir/default_fr.aspx?u=http%3a%2f%
2flexikon.izynews.de%2fde%2flexw.aspx%3fdoc%3dSpezial%253aRecentchanges

http://lexicon.izynews.be/nl/lexw.aspx?doc=Speciaal:Recentchanges

The are running a live copy of Wikipedia at the expence of the Wikimedia
foundation. Can the be blocked?

Greetings,
[[w:nl:gebruiker:Walter]]


subject: [Wikitech-l] Website to block II

body:
Those also please;
http://www.wikinl.info/index.php?title=Speciaal:Recentchanges

http://www.wikien.info/
http://www.wikide.info/
http://www.wikies.info/
http://www.wikifr.info/ etc ..

Besides pulling the pages live from Wikipedia the also say "Copyright ? MMV
Home (e-mail) 2005." and that the content is under "Attribution-NonCommercial-
ShareAlike 2.0"

Walter


list: wikipedia-l

from_name: Alphax

subject: [Wikipedia-l] Wikipedia, Emergence, and The Wisdom of Crowds

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ray Saintonge wrote:
> Delirium wrote:
>
>> Stirling Newberry wrote:
>>
>>> My point was that Mark does not understand the language of
>>> debate, his clear poisoning the well attack here is an excellent
>>> example of it.
>>
>>
>> Since I have not been participating in this thread, I'm not sure to
>>  what you mean to refer.  Your previous argument in this thread was
>>  with Ray Saintonge, not with me.
>
>
> Fantastic!  ... and I thought I was arguing with Jean-Baptiste
> Soufron. I suppose if I worked hard at it I could make a distinction
> between "explicitly" and "specifically", but the former may indeed be
> a superior choice.
>
> The question that set us off in this direction was whether someone
> had the right to put his work into the public domain.  I maintain
> that he does.  To put this in terms of the distinction between "malum
>  prohibitum" and "malum in se" is absurd in the absence of a "malum"
> of any kind in such an act.  Is Stirling proposing that someone
> should be fined for putting his writings in the public domain?
>
> Ec

Since I seem to kill every thread I post to, I'll end this one.

I used {{MultiLicenseMinorPD}} until about 2 days ago, when I say the
following on it's talk page:

> Because it's actually legally impossible to grant one's own works
> into the public domain in the U.S. and U.K., and this creates serious
>  potential legal problems, I will deprecate this tag if there is no
> dissent for 4 days. Please see [[Wikipedia:You can't grant your work
>  into the public domain]] for a full explanation along with some
> authoritative sources, including the U.S. Copyright Office. I have
> created the tags {{TextLicenseMinorFreeUse}}, which reflects the
> intent of this template. [[User:Dcoetzee|Deco]] 03:34, 8 Apr 2005
> (UTC)

As I read it (IANAL), you can't place your work into the public domain
because:

> Any work receives copyright by default and copyright law generally
> doesn't provide any special means to "abandon" copyright so that a
> work can enter the public domain

and

> Some claim that under many jurisdictions, a statement absolving a
> copyright or "granting" a work into the public domain has no legal
> effect whatsoever, and that the owner still retains all rights to the
> work not otherwise released. This person would then have the legal
> right to prosecute people who use the work under the false impression
> that it was in the public domain. It is certainly true that under
> some jurisdictions, it is impossible to release moral rights, though
> that is not the case in the United States.

(From [[Wikipedia:Granting work into the public domain]] and [[Public
domain]])

*However*, you /can/ release things under a free-for-any-use licence,
like {{CopyrightedFreeUse}}, {{NoRightsReserved}}, {{cc-sa}}, etc.

(Hopes flame war will end now)

- --
Alphax
GnuPG key: 0xF874C613 - http://tinyurl.com/8mpg9
http://en.wikipedia.org/wiki/User:Alphax
There are two kinds of people: those who say to God, 'Thy will be done,'
and those to whom God says, 'All right, then, have it your way.' - C. S.
Lewis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCfxpb/RxM5Ph0xhMRAr22AJ9LefnIRX6v42Y2On6/pEdKj4OPswCfSvfS
RIfW6PMpqrRc/j8D48xIVWc=
=nshJ
-----END PGP SIGNATURE-----


from_name: Delirium

subject: [Foundation-l] Wikibreak from JAWP

body:
Daniel Mayer wrote:

>>Unfortunately trolls seem to be very active and winning in a number of
>>languages.
>>
>>
>
>This is not good. Perhaps setting up arbitration committees or something
>similar in those projects will help. Jimbo would need to give that type of
>thing the authority its needs to function.
>
>
Proposals from within the various language communities would be nice
too---there's no specific reason every Wikipedia has to function
identically to the en: one, which is in a lot of ways a sort of special
case.

Is the problem that there are no proposals for what to do, or no
authority to implement the proposals, or does the "outside world" just
not know what's going on in a lot of Wikipedias because of language
barriers?  I confess I have very little idea what's going on in
Wikipedias other than en, de, and fr, and I suspect that's true of a lot
of people---even ja, a very large and active one, is pretty much a black
box to me as a non-Japanese-speaker, and doubly so for many others.

-Mark


subject: [Foundation-l] Wikibreak from JAWP


from_name: David A. Desrosiers

subject: [Wikitech-l] Longterm software strategy

body:
> The other is to keep refactoring the PHP codebase (and it's been
> much changed since you left it, Lee) and, optionally, rewrite
> particular hotspots in another language.

	The downside of this are for people like myself who run an
external (though not public) version of mediawiki exclusively for use
in taking parts of it to convert to other formats (in my case, mobile
and handheld formats). If you change the core language mediawiki is
driven by, you further burdon external contributors and supporters of
mediawiki as a whole.

	..unless you're talking about a rewrite _exclusively_ for use
on the Wikipedia/etc. servers, and not for the main SF.net project as
distributed to the community. I suspect you're not talking about this
approach because that means maintaining two separate (and gradually
diverging) codebases.

> In particular, PHP tends to impose an architecture where each
> request is served by an entirely new script invocation: you have to
> build any information up from scratch on each hit, and sharing
> things like localization tables between invocations is kind of hard.

	(Below comments are paraphrased from a conversation I just had
about an hour ago with Rasmus Lerdorf):

	Isn't this exactly what ICU[1] was developed to solve? ICU
	automatically sticks requests in shared memory in order to
	optimize itself across different processes on the same server.

	The goal should be that scalability is pushed out into the
	individual layers and doesn't become a factor at the language
	level like with Java or ASP.

	To be truly scalable, nothing should prevent subsequent
	requests to be handled by different physical web servers. If
	you want to impose an application layer dependance on shared
	memory on a single physical server, you'll need to do that
	yourself.

	And no, it is not hard to use shared memory from PHP.

[1] http://www-306.ibm.com/software/globalization/icu/index.jsp

David A. Desrosiers
desrod at gnu-designs.com
http://gnu-designs.com


from_name: Lee Daniel Crocker

body:
On Tue, 2005-05-10 at 00:47 +1000, Tim Starling wrote:

> One important thing to note is that the parser is a performance problem,
> not a scalability problem. We really can throw more hardware at it, and
> that will fix it quite nicely. In my opinion, our biggest performance
> problem at the moment is not the parser, it's replication lag and
> database load balancing. There's lots of work that has to be done there.

I agree, I don't think the parser's a big issue, although it would be
nice for a bit snappier response.  In hindsight, storing the wikitext in
a database was a mistake.  There's already a wonderful piece of software
highly optimized and scalable for storing randomly accessed variable-
sized chunks of text with lots of tools for backup, replication, and so
on; it's called a file system.  Storing the wikitext itself in something
like Reiserfs would probably speed it up, and also speed up access to
the rest of the metadata in the database which would become much
smaller.

--
Lee Daniel Crocker <lee at piclab.com>  <http://www.piclab.com/lee/>
<http://creativecommons.org/licenses/publicdomain/>


subject: [Wikitech-l] Re: Reloading WIKI database

body:
> Yup, XAMPP's mysql config did the trick, importing en's cur on a
> machine inferior to yours in 32 mins.

	Ironically, the last 8 hours have been spent trying to import
the 2.5gb Wikipedia cur_table.sql dump into a local MySQL instance
using InnoDB on a 2.1Ghz machine with 3gb of RAM and _very_ fast
disks.

	What's the trick to speeding this up, other than using MyISAM?

David A. Desrosiers
desrod at gnu-designs.com
http://gnu-designs.com


subject: [Wikitech-l] Longterm software strategy

body:
On Mon, 2005-05-09 at 12:43 -0700, Brion Vibber wrote:

> A possible middle road is to rewrite the core wiki engine to a separate
> daemon, and adapt the existing PHP user interface to call into it for
> much of the backend work that actually touches data.

That's the approach I'd favor.  The existing PHP code represents a lot
of good user-interface work for which PHP is perfectly suited.  The
underlying stuff could easily be split up into multiple daemons (say,
one for wikitext, one for images, one for equations,...) that could
feed the PHP front-end.

This would also allow incremental development, since each of the daemons
could be written and attached indicidually without disturbing the rest
of the codebase.

> Our biggest, nastiest burden is with internal communications: the
> database changes too much. We have to wait on things getting sent,
> received, applied, and copied around, and lagging databases send
> everything into the toilet fast.

Yep.  That's why I think the bulk of the text should be stored in a
plain filesystem, where those problems are already well-known and
solved, for the most part.  That would reduce the database to just
metadata, which would be much smaller and more efficient.

> ...Better distinguishing between requests
> that need to be absolutely current and requests where it's ok to load a
> page that's 30 seconds out of date could make much better use of the
> slave servers.

Yes!  There's only one tricky part for which we may have to consider
creative implementations: I tried as much as possible to take style
markup (especially skin-specific) out of the rendered wikitext to
allow it to be cached, but there's one case that's still a problem:
red links (i.e., links to non-existent pages).  Users shouted at me
that this was a sine-qua-non feature, and so I had to leave it in.
But it makes caching rendered wikitext hard, and slows down rendering.
One alternative is to simply tolerate them being out of date for the
life of the cache.  Another is to possibly update the cache in some
cheaper way.  Yet another is to optimize the hell out of discovering
the simple existence of a page, so that it's not a bottleneck in
rendering (say, by having a daemon that keeps a one-bit field for
every page using a spell-checker data structure)

> If there's a really strong reason for a rewrite, then we should start
> planning a (cleanly implemented, *compatible*, complete) rewrite, making
> use of the existing parser tests and other tests in existence and yet to
> be written to make sure it'll really be able to take over. If we do, we
> should probably target the end of this year or early next year for
> taking it live. (No need to rush though; if we're going to rewrite, the
> point is to plan ahead and do it right.)
>
> I'm not totally convinced that there is a really strong reason, though.

I'm all for your method, and I agree it's not an urgent need.  But I
think we can slip the timeline even more.  The existing codebase will
eventually be a liability, but I think we can throw hardware at it for
a year or two.  Also, if we go the route of making independent daemons
linked into the existing UI code, we don't have to deploy all at once.
We could, for example, make and deploy the math daemon as a proof-of-
concept, work out bugs with that, then do the others afterward.

Another thing to consider: at least some of the wikipedia-driven
development will be totally unnecessary for mediawiki as a general-
purpose open source project.  We may want to decouple those projects
at some point.

--
Lee Daniel Crocker <lee at piclab.com>  <http://www.piclab.com/lee/>
<http://creativecommons.org/licenses/publicdomain/>


subject: [Foundation-l] Wikiversity=>Wikisophia

body:
On Mon, 2005-05-09 at 23:10 +0200, Erik Moeller wrote:

> Angela suggested the name Wikisophia.org/.com, which is currently owned
> by Peter Danenberg (WikiTeX). I loved the idea immediately: the Greek
> sophia means "wisdom", but also has many other meanings in the area of
> learning. It is specific enough to be useful and vague enough to not
> limit the project very early in its nature or scope.
>
> Peter is willing to give us the name if we push WikiTeX a little to get
> it security-reviewed and installed on our servers, which seems like a
> fair deal to us.

I don't see how it's acceptable for us to agree to any conditions that
affect our prerogatives for software use.  We need to use whatever
software best suits our purposes.  WikiTeX is nice work, and we may
very well end up using it or something similar.  But that has to be our
choice, and ours alone, based on our needs.  We can certainly agree to
give him money and/or some official imprimatur, but not our freedom.

Secondly, what's wrong with good old fashioned plain-English multiple
word names for things like "Wikimedia Schools Project" or "Wikimedia
Offline" or something?  The trend of squeezing things into obscure
neologisms strikes me as too cute for a serious project.

--
Lee Daniel Crocker <lee at piclab.com>  <http://www.piclab.com/lee/>
<http://creativecommons.org/licenses/publicdomain/>


subject: [Foundation-l] Wikiversity=>Wikisophia


from_name: blankfaze

subject: [WikiEN-l] Usernames advertising websites

body:
I have just noticed http://en.wikipedia.org/wiki/User:GordonWattsDotCom ...
It seems to me to be somewhat inappropriate to create a username advertising
a personal website, but I didn't see anything in the Wikipedia username
policy ( http://en.wikipedia.org/wiki/Wikipedia:Username ) that says
anything about adverts...

So I thought I'd pose the issue to the mailing list, see what you all think.

--
! blankfaze
*the good times
are killing me*


from_name: MacGyverMagic/Mgm

subject: [WikiEN-l] Abuse of blocking privileges

body:
Look at Eric's reply. It never changed.
I don't see any reason to strip someone from their admin powers for
enforcing the rules.

--Mgm

On 5/9/05, Richard Rabinowitz <rickyrab at eden.rutgers.edu> wrote:
>
> No offense, but I thought this was a 3RR rule - 3 reverts and revisions
> on a page. Since when did it go to 5 reverts/24 h?
>
> On Sun, 8 May 2005, Leif Knutsen wrote:
>
> > User:Jtdirl blocked me (Leifern) for allegedly violating the 5 reverts in 24 hour rule.  This is both unreasonable and an abuse of his admin privileges, for the following reasons:
> > - There are actually 4 reverts in about 4 hours
> > - The reversions were of deletions of graphs - since it's simply not possible to reword images, I had little option besides reverting the deletions
> > - The person who kept deleting the graphs did very little to justify them besides saying that they were irrelevant
> > - My adversary (Geni, also an admin) reverted three times, but this apparently didn't bother Jtdirl
> > - Jtdirl has an axe to grind - we had an editing dispute that he lost about heirs apparent - I can't help but think this is a vindictive act.
> > - Jtdirl gave no warning, made no effort to mediate, simply went ahead and blocked
> >
> > I don't know what the remedy for this is, but I would propose that both Jtdirl and Geni lose their admin privileges.  If I am not unblocked immediately, I am happy to find another hobby.  I believe my contributions speak for themselves - that would be a great loss for the WP community.
> > _______________________________________________
> > WikiEN-l mailing list
> > WikiEN-l at Wikipedia.org
> > http://mail.wikipedia.org/mailman/listinfo/wikien-l
> >
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: ultrablue at gmail.com

subject: [WikiEN-l] Wikipedia widget for new Macintosh OS release

body:
Speaking of widgets, has anybody tried coding a Wikipedia panel for
the equivalent Deskbar thing in the upcoming release of Windows
Longhorn? I doubt Microsoft would be so happy to promote it on their
sites though, considering the renewed competition from Encarta.

~Mark

On 5/8/05, Sheldon Rampton <sheldon at prwatch.org> wrote:
> I see that someone has already written a Wikipedia widget for the
> dashboard on the new OS X 10.4 ("Tiger") release for the Macintosh:
>
> http://www.apple.com/downloads/macosx/dashboard/wikipedia.html
>
> In a related development, someone else has written "WikityWidget," a
> widget that lets Mac users create their own personal wiki that runs
> locally on their computer:
>
> http://inkspotting.com/wikity/
>
> Unfortunately, the WikityWidget only supports the CamelCase link
> style, and I think Wikipedia's syntax is much more powerful and
> flexible.
>
> It would be great if someone could develop a WikityWidget-like tool
> that supports the Wikipedia syntax. I've been using a local
> installation of MediaWiki on my laptop to keep various notes for my
> personal use, but it would be easier to have the same functionality
> available on my dashboard. Also, it would help to further popularize
> the Wikipedia syntax, which I'd like to see become the basis for a
> standard wiki syntax even outside of MediaWiki.
>
> --Sheldon Rampton
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l
>


from_name: geni

subject: [WikiEN-l] Abuse of blocking privileges

body:
On 5/9/05, Richard Rabinowitz <rickyrab at eden.rutgers.edu> wrote:
>
> No offense, but I thought this was a 3RR rule - 3 reverts and revisions
> on a page. Since when did it go to 5 reverts/24 h?

It is more than three (ie 4 or greater) in 24 hours. Always has been.

--
geni


from_name: Yann Forget

subject: [Foundation-l] General copyright policy

body:
Hi,

Following the discussion about stamp copyright status on Commons (and many
other discussions elsewhere), I thing we need better guidelines for works
without unknown or unreachable author(s). This issue keeps coming back every
now and then, takes our time and fustrates users because no clear solution is
in sight.

So I think we should define a general policy about these works without getting
paranoid about it. They are numerous works whom the author is not known or
can't ever be reached. This affects all projects, but especially Commons and
Wikisource. This concerns only "minor" works. If the work is famous, then the
copyright owner is known, so the question doesn't arise.

I?will take examples to show what kind works I am talking about. According to
people I had on the phone from the French Postage Stamp Museum (Mus?e de la
Poste), the copyright for French postage stamps belongs to the drawer and the
engraver. So according to them, we have to inquire about each drawer and
engraver for these stamps. They are hundreds of unknown artists for French
stamps only and this is obviously not a workable solution.

See these stamps from 1917 to 1936:
http://fr.wikipedia.org/wiki/Image:Jeux_Olympiques_1924.jpg
http://fr.wikipedia.org/wiki/Image:PA_Marseille_rouge.jpg
http://fr.wikipedia.org/wiki/Image:PA_Paris_violet.jpg
http://fr.wikipedia.org/wiki/Image:Orphelins_5plus5.jpg
This is not even the worst case, the name of the author is readable.
I?tried to find more about them without success.
Then there are many others where the name of the author is not even known.

As a workable solution, I propose something like: If the drawer and the
engraver are unknown or unreachable, and the work is more than X years old
(70???50 ?), this is similar to anonymous work, so we can publish it. So we
still have to decide what are the criterias for considering the copyright
owners unreachable or unknown, but I think an agreement could be reached
about this.

Regards,

Yann
--
http://www.non-violence.org/ | Site collaboratif sur la non-violence
http://www.forget-me.net/ | Alternatives sur le Net
http://fr.wikipedia.org/ | Encyclop?die libre
http://www.forget-me.net/pro/ | Formations et services Linux


subject: [Foundation-l] General copyright policy


from_name: Austin Hair

subject: [Wikitech-l] Longterm hosting strategy

body:
> Come on, stupid, this is free software.  Writing running code is
> everything, making suggestions is nothing.  People laugh at
> anybody who writes suggestions instead of code.

I guess it's a bit late to point out that I didn't mean that last
sentence as a moral imperative.

As it happens, I do code for other Wikimedia development efforts, but
that shouldn't have any bearing whatever on my "big picture visionary
statements," to quote Jimbo's original message.  An idea is an idea,
and it won't fall on one man to implement it, no matter whose it is.

You can be assured that I'll be there for a future rewrite, should it
happen, but it's still secondary to the priority of keeping myself out
of the rain.  (Not all of us can live in a refrigerator box, like
brion here.)

> --
>   Lars Aronsson (lars at aronsson.se)
>   Aronsson Datateknik - http://aronsson.se

--
main(){char*s="2)$%\3404(%\3407!,253\312",i=0;
while(i["]&&down==!up&&s["]&&putchar('@'+(i++)
[s]));return!i;} // http://www.austinhair.org/


from_name: Georg Jaehnig

subject: [Wikitech-l] Our own IRC server

body:
Hi,

2005/5/9, Tim Starling <t.starling at physics.unimelb.edu.au>:
> We now have an IRC server set up, for the sole purpose of delivering
> recent changes information.

This is really nice. As I wrote in the thread "Wikipedia Zeitgeist"
[1] it could be useful to have a log of the recent changes.  Not only
to realize the Zeitgeist but also to do some other statistics for
everybody.

Is it possible to make a tar.gz file for every day and channel available?

[1] http://mail.wikipedia.org/pipermail/wikitech-l/2005-May/029164.html
--
| Jorge | Nur lernen, was man will:
          http://www.sudbury.de


from_name: Erik Moeller

subject: [Wikitech-l] Longterm hosting strategy

body:
Austin et al.-

is there any actual use case of a dynamic content website that handles
as much traffic as we do with less hardware? My guess would be that in
most cases of "professional" deployment, the hardware budget for a
network of sites like Wikimedia would be one or two orders of magnitude
larger than ours at the very least, not to mention an impressive
full-time staff.

The truth is probably that this rag tag team of volunteers has
accomplished things on a shoestring budget -- we're one of the largest
websites on the planet! -- where countless dot coms have utterly failed
with a lot more resources at their disposal. And Wikipedia is not just
any website, it's an extremely dynamic and rapidly growing one.

Much, much development energy in the last years has focused on
performance optimization, from parser and message caching in the
database to memory caching with memcached, from bytecode caching to
Squid proxies to load balancing. Profiling has been done, problem areas
of the code have been isolated and optimized, slow queries are only
periodically run.

That is not to say that we shouldn't invest in both software development
and hardware/network deployment, that we don't need to decentralize our
infrastructure, or that we don't need to build reserves to cope with
growth better than we do. Perhaps we can work on a roadmap which
outlines the key issues, and then the Board could allocate resources to
address them?

Erik


body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ray Saintonge wrote:
> Alphax wrote:
>
>> Since I seem to kill every thread I post to, I'll end this one.
>
>
> That's a bloody arrogant attitude.
>

Sorry, I'm sick of how long this has dragged on for, and often my posts
are never replied to. I see you have no sense of humour.

>> I used {{MultiLicenseMinorPD}} until about 2 days ago, when I say the
>>
>> following on it's talk page:
>>
>>
>>> Because it's actually legally impossible to grant one's own works
>>> into the public domain in the U.S. and U.K., and this creates serious
>>> potential legal problems, I will deprecate this tag if there is no
>>> dissent for 4 days. Please see [[Wikipedia:You can't grant your work
>>> into the public domain]] for a full explanation along with some
>>> authoritative sources, including the U.S. Copyright Office. I have
>>> created the tags {{TextLicenseMinorFreeUse}}, which reflects the
>>> intent of this template. [[User:Dcoetzee|Deco]] 03:34, 8 Apr 2005 (UTC)
>>>
>>
>> As I read it (IANAL), you can't place your work into the public domain
>> because:
>>
> Quoting yourself as an authority is a nice trick if you can get away
> with it.
>

You missed the tyop then - it should have been clear that /I/ wasn't the
one to write that, from the username and the date. Quoting a single
sentence out of context is a nice trick too.

Doesn't Wikipedia quote itself as an authority? /And/ get away with it?

> Your statement that it is impossible to grant one's works into the
> public domain is patently false.  Copyright is an intellectual property
> right, and it is fundamental to property rights that the owner have the
> right to dispose of his property in whatever manner he sees fit.
> I looked at the page which you mentioned and the only thing that
> purports to be from the copyright office is a single unverifiable
> sentence from a letter received by User:Dcoetzee.  It is completely out
> of contest.  For that sentence to be credible one would need to see the
> entire letter, as well as the letter from the user showing the questions
> that he asked.
>

I was giving an opinion, and some reasons why I had formed that opinion.
Anyway, I /thought/ that public domain was for things which either had
no copyrightable aspects (eg. with {{PD-ineligible}}) or the copyright
had expired. From what I read, it appeared that you couldn't just
relinquish your rights over something. I'm about 99% certain that you
will never lose authorship rights (ie. you are always the origanl
author), but you only lose royalty etc. rights if you sell them to
someone else, or you have been dead for a while. I'll discuss this with
an economist friend of mine.

>>> Any work receives copyright by default and copyright law generally
>>> doesn't provide any special means to "abandon" copyright so that a
>>> work can enter the public domain
>>>
> While it's true that a work receives a copyright by default as a
> requirement of the Berne Convention, the absence of "special means is
> not a barrier to putting a work into the public domain.
>

Well, I'm not a copyright lawyer, nor did I ever claim to be. In fact, I
explicity stated that I wasn't.

>>> Some claim that under many jurisdictions, a statement absolving a
>>> copyright or "granting" a work into the public domain has no legal
>>> effect whatsoever, and that the owner still retains all rights to the
>>> work not otherwise released. This person would then have the legal
>>> right to prosecute people who use the work under the false impression
>>> that it was in the public domain. It is certainly true that under
>>> some jurisdictions, it is impossible to release moral rights, though
>>> that is not the case in the United States.
>>>
> Moral rights are another matter, and I realize that they are not a part
> of the US law on this.  For the moment let's stick to US law.  Once the
> situation there is clear it will be easier to consider the matter in the
> light of the law in other countries.
>

Well, maybe we should just leave it to the lawyers, and stop wasting our
time arguing about things we don't know enough about to reach a proper
conclusion.

> Please do one of two things:
>    1. Cite the section of US statute law which explicitly denies the
> right to abandon all one's rights in a work, or
>    2. Cite a judicial decision which has clearly denied a person's right
> to abandon his copyright.
>
> In the absence of this I would conclude that you don't know what you're
> talking about.
>

1. I can't, because I don't have ready access to the US statutes, nor
the legal knowledge to understand them. The small amount of *accurate*
(not from TV) legal knowledge I have is not about the US anyway. English
is spoken in many other places than the US, like the places the original
speakers of English went to apart from North America.

2. There probably haven't been any, and see 1.

3. I never said that I did. Thankyou for making it oh-so-clear as what
the actual legal situation is.

>> *However*, you /can/ release things under a free-for-any-use licence,
>> like {{CopyrightedFreeUse}}, {{NoRightsReserved}}, {{cc-sa}}, etc.
>>
> These are alternative ways of doing things.
>

I hope so. That's why I've only attempted to release *minor edits*
(which are most likely not copyrightable anyway, due to the /extremely/
minor nature of them) into the public domain, IF this is indeed possible.

>> (Hopes flame war will end now)
>>
> :-D
>

Are we there yet? :-P

- --
Alphax
GnuPG key: 0xF874C613 - http://tinyurl.com/8mpg9
http://en.wikipedia.org/wiki/User:Alphax
There are two kinds of people: those who say to God, 'Thy will be done,'
and those to whom God says, 'All right, then, have it your way.' - C. S.
Lewis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCf0ki/RxM5Ph0xhMRAnbzAJ9902zHl7Fg4U8V4mFGmBNpigw/1QCgqcqz
9qinntYowqmLdIwiOHnrghM=
=RrPy
-----END PGP SIGNATURE-----


subject: [Foundation-l] Wikiversity=>Wikisophia

body:
On Tue, 2005-05-10 at 04:52 +0200, Erik Moeller wrote:

> Of course we're not going to install WikiTeX if we decide that there's a
> better option, but that seems unlikely. WikiTeX is one of the most
> requested features from our users.

Just because users demand something, that doesn't mean it's really
what they need.  Part of the job of good software design is filtering
user input to determine what the user's problem really is, and finding
the best way to solve that problem regardless of what the user thinks
is the right solution.

I like WikiTeX, and the formal wiki syntax I'm working on has a nearly
identical extension-based syntax for the kinds of things it does.

It might be a good idea to, say, promise to devote some resources to do
a security review and make WikiTeX part of the mediawiki software on
SourceForge that other wikis install, but not commit to installing it
ourselves until we do more work on performance as well.

> Wikimedia is not an English language project, for starters. This makes
> it necessary for English language derived names like Wiktionary to be
> localized, which then leads to confusion when you go to a domain like
> pl.wiktionary.org and end up on a site called Wikis?ownik. Of course, to
> a certain extent, you will never be able to avoid this, but at least in
> the Latin languages, you can strive for a name which doesn't require
> localization. Wiktionary is not too bad because it's still a neologism,
> whereas something like "Wikimedia Dictionary" would be much worse.

I don't see that at all--plain words translate into plain words
directly: "Dictionnaire Wikip?dia", "Wikipedia S?ownik", etc.
Trying to find a latin-based neologism or something doesn't avoid
the problem of translation, it just warps it a bit.

> A short and unique name is also useful for searching the project and
> marketing it...
> FWIW, the "cute" part of "Wikisophia" is not "-sophia", but "Wiki", and
> we're pretty much stuck with that no matter what we do.

Fair enough.  "Wikisophia" is a fine name, and might not have to be
translated in some languages (though Bulgarians might think it's just
a local chapter or something :-).  I just don't think a serious
academic project should fall into the habit of marketing-speak, even
if it would be effective (which is far from given).

--
Lee Daniel Crocker <lee at piclab.com>
<http://creativecommons.org/licenses/publicdomain/>


subject: [Foundation-l] Wikiversity=>Wikisophia


from_name: Leif Knutsen

subject: [WikiEN-l] Re: WikiEN-l Digest, Vol 22, Issue 24

body:
Timwi <timwi at gmx.net> wrote:
> Leif Knutsen wrote:
>
>> If I am not unblocked immediately, I am happy to find another hobby.
>> I believe my contributions speak for themselves - that would be a
>> great loss for the WP community.

>And again. Why do newbies keep posting this? How many people actually
>fall for this? How many people actually read this and go "OMG we're
>gonna lose a valuable contributor! Must unblock quick!!!"?

I'll remember next time to show greater humility before all those wiser than
me, but perhaps you will also let me know when I've edited enough articles
to move from being "newbie" to "peon cadet," or whatever the next level is.

I do appreciate the need to enforce rules and be consistent about it, but I
also think that a) a warning is in order before blocking someone; b) the
person who is being blocked should have some means of defending his/her
actions; and c) it should always raise flags in a situation like this, when
the person (an admin) whose deletions were reverted reported the reverts;
and another, who only a few weeks before had lost a dispute with me, jumped
at the opportunity to block me. I'll grant they both acted within the letter
of the law, so to speak, but they both misbehaved - and badly. If there's a
pattern of such misconduct over time among such admins, they shouldn't be
admins - after all, being an admin involves a responsibility that is greater
than being an editor, as this episode amply demonstrates.

As for my "threat," it was meant earnestly. I work 60 hour weeks, am the
parent of two kids, one of whom has special needs, and I have a long
commute. I am doing this partly because I think it's fun and partly because
I think it's important. I expect lots of disagreements here, and plenty of
obnoxious, unreasonable, and ignorant people. But I also expect that the
role of admin is taken seriously. You all don't have to be perfect, but
there's got to be a higher standard among you; and I can safely predict that
this whole enterprise will collapse under its own weight unless the
responsibility of doing the right thing isn't reinforced and if necessary
enforced. The two individuals who (probably inadvertently) colluded to block
me should be ashamed of their actions, and I'll stand by that.

All the best,

Leifern


body:
On Tue, 2005-05-10 at 03:44 +0000, ?var Arnfj?r? Bjarmason wrote:
> > like Reiserfs would probably speed it up, and also speed up access to
> > the rest of the metadata in the database which would become much
> > smaller.
>
> How about something like a version control system, subversion for
> example, I don't know how it would do speed wise for something like
> this but with that you'd get

Waaaay too slow (have you ever used Subversion?)  But it might not be
a bad idea to put a WebDAV/DeltaV front end on whatever we create to
make it possible for third-party tools to access it.

--
Lee Daniel Crocker <lee at piclab.com>
<http://creativecommons.org/licenses/publicdomain/>


body:
Timwi wrote:

> And again. Why do newbies keep posting this? How many people actually
> fall for this? How many people actually read this and go "OMG we're
> gonna lose a valuable contributor! Must unblock quick!!!"?

Er, because they're *new*? They don't know what's come before.


from_name: Faraaz Damji

subject: [WikiEN-l] Abuse of blocking privileges

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

geni wrote:
>>I don't know what the remedy for this is, but I would propose that
both Jtdirl and Geni lose their admin privileges.
>
>
> Again? Can you show where I have abused my admin powers?

"My adversary (Geni, also an admin) reverted three times, but this
apparently didn't bother Jtdirl"

It shouldn't have bothered him.  The limit is three reverts per day.

- --
Blog: http://frazzydee.ca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCgBFRT65h0kZaRnYRAs0FAJ9/QX8ieg5N7VSNup0NR0n/y9fjlwCeL4lJ
J0pAUjz0TzqxeEdmjNK2BTc=
=YeYv
-----END PGP SIGNATURE-----


body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pete/Pcb21 wrote:
> Timwi wrote:
>
>> And again. Why do newbies keep posting this? How many people actually
>> fall for this? How many people actually read this and go "OMG we're
>> gonna lose a valuable contributor! Must unblock quick!!!"?
>
>
> Er, because they're *new*? They don't know what's come before.

Very few people will actually make a significant difference to what
happens here.  We all like to think that things would fall apart on
Wikipedia without us, but it's rarely true.

It kinda pisses me off when people 'threaten' to leave if we don't give
in to their requests.  It comes off as really arrogant and somewhat like
attempted blackmail, IMHO.

- --
Blog: http://frazzydee.ca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCgBHaT65h0kZaRnYRAkPNAJoCbr3RWI7qWfE/IPvkJR7waBXWOgCZARE2
rWHGATEuF0B9vws1E4rAoAY=
=Z8Hj
-----END PGP SIGNATURE-----


from_name: Bill Konrad

subject: [WikiEN-l] Abuse of your services

body:
"Ray Saintonge" <saintonge at telus.net> wrote:
>
> I have never used Usenet as a source of information, and, given the
> controversy that it engenders, I would only do so with extreme caution.  I
> would make no absolute rule against using it, but a critical reader needs
> to be aware that its use as a reference will taint the credibility of the
> material.  The value of an article depends on the combined credibility of
> its sources and integrity of its contributors.

Yes, I agree. In general, Usenet is close to the bottom of the barrel in
terms of reliability. However, there is still some valuable information to
be found on Usenet in between the volumes of drek and I think it is
misguided to pre-emptively bar it as a source. It should certainly be
deprecated, and wherevery possible other sources should be substituted. But
much of the better quality material to be found on Usenet is really more a
sort of a tertiary reference, summarizing and often listing other
references. As a hypothetical example, if Joe Blow comes along and sees that
there isn't any topic about some old bridge over the river backwater, but he
knows of a Usenet FAQ in alt.obscure.bridges.moderated describing the bridge
and decides to write an article about the bridge based on the FAQ, then I
think he should encouraged to do so and to cite the FAQ as a source. The FAQ
might well mention arcane some print sources that are unavailable to Joe (or
maybe he's not interested in looking them up himself or maybe he's clueless
about how to incorporate citations from another source into his writing). If
using Usenet as a source is summarily barred, then the other sources for
that information would not be very easily available for future editors who
might be interested in improving the article. And if the Usenet FAQ turns
out to be a work of fiction, then having it identified as a source for the
article will also make it easier for future editors to weed out the garbage.

Bkonrad


subject: [Wikitech-l] Longterm software strategy

body:
> There are a couple possibilities here. One is to rewrite MediaWiki in
> some other language entirely, say Python or C# or whathaveyou.

This is obviously the most difficult and problematic, but could
perhaps be a target for 3.0 (or even 4.0).

> The other is to keep refactoring the PHP codebase (and it's been much
> changed since you left it, Lee) and, optionally, rewrite particular
> hotspots in another language.

This would be a minimum, I think.  I'd like to see what the Flex
parser gives us, although I suspect an OCaml implementation may be
able to do one better.

> A possible middle road is to rewrite the core wiki engine to a separate
> daemon, and adapt the existing PHP user interface to call into it for
> much of the backend work that actually touches data.

Any external parser may need to be daemonized anyway for speed, even
taking OS-level binary caching into consideration.  Breaking out the
database engine with it offers the possibility of a more flexible
database solution, although that may be best handled as part of the
object store project.

> If there's a really strong reason for a rewrite, then we should start
> planning a (cleanly implemented, *compatible*, complete) rewrite, making
> use of the existing parser tests and other tests in existence and yet to
> be written to make sure it'll really be able to take over. If we do, we
> should probably target the end of this year or early next year for
> taking it live. (No need to rush though; if we're going to rewrite, the
> point is to plan ahead and do it right.)
>
> I'm not totally convinced that there is a really strong reason, though.

Making it a goal now ensures that we *can* take our time "doing it
right," *before* it becomes an immediate need.  A comprehensive test
suite is a must for this, and I know a lot of work has been put into
improving the one we have over the past few weeks.  And, of course,
there's still room for optimization in the current codebase.

> -- brion vibber (brion @ pobox.com)

--
main(){char*s="2)$%\3404(%\3407!,253\312",i=0;
while(i["]&&down==!up&&s["]&&putchar('@'+(i++)
[s]));return!i;} // http://www.austinhair.org/


from_name: John Fader

body:
On 5/3/05, Michael Keppler <Michael.Keppler at gmx.de> wrote:
> John Fader schrieb:
> > Surely MySQL on windows can't be *this* bad?

> I just clocked the import of a 924 MB German cur table from March 22 on
> my AMD64 3500+ 2GB workstation running Windows XP with MySQL 4.1.11, and
> it took 5 minutes and 36 seconds.

Yup, XAMPP's mysql config did the trick, importing en's cur on a
machine inferior to yours in 32 mins.

Thanks heaps!

--
John Fader


subject: [Foundation-l] Wikiversity=>Wikisophia

body:
(Cross-posted on [[m:Talk:Wikiversity]] and briefly summarized on
de.wikiversity.org)

During and after our visit to the free software conference in South
Africa, Angela and I talked a lot about the Wikiversity project, and the
potential Wikimedia has to develop a truly global, free institution of
learning as a new project.

As you probably know, these discussions are currently focused on
	http://meta.wikimedia.org/wiki/Wikiversity
and the talk page.

Don't panic: We're still a long way from launching anything. I'm not
going to push this until we have the server situation under control and
the existing projects have stabilized a bit. Nevertheless, there's one
issue that I'd like to resolve now, which is the naming of the project.

Angela, Jimbo, Daniel Mayer and I agree that the name Wikiversity is
problematic in that it ties the project very strongly to the idea of
traditional universities. This may lead to certain expectations as to
its structure and the services it will provide (e.g. faculties,
degrees), but also limit the project in other ways, e.g., by being
perceived primarily or only as an institution of teritary learning.

I'd like us to look at ideas for primary and secondary education as
well, and I don't want to run into a wall because the established people
of the Wikiversity community will say "It's an electronic university,
this doesn't belong here."

Angela suggested the name Wikisophia.org/.com, which is currently owned
by Peter Danenberg (WikiTeX). I loved the idea immediately: the Greek
sophia means "wisdom", but also has many other meanings in the area of
learning. It is specific enough to be useful and vague enough to not
limit the project very early in its nature or scope.

Peter is willing to give us the name if we push WikiTeX a little to get
it security-reviewed and installed on our servers, which seems like a
fair deal to us.

So, after discussing this in a small circle, I'd like to announce my
intention to move the relevant pages on Meta and edit the summary to
reflect the name change. This does not affect the existing efforts under
the Wikibooks domain which use the "Wikiversity" label, but only any
potential future eLearning/eTeaching project we intend to pursue.
de.wikiversity.org could be renamed and moved to the new domain once it
is owned by Wikimedia.

Thoughts and comments are welcome. Hopefully, we can find a consensus on
this without needing a vote.

All best,

Erik


subject: [Foundation-l] Wikiversity=>Wikisophia


from_name: Deathphoenix

body:
Not to comment on the specifics of your case, but don't forget that
other people have their own stories and their own hardships.

Leif Knutsen wrote:

>I'll remember next time to show greater humility before all those wiser than
>me, but perhaps you will also let me know when I've edited enough articles
>to move from being "newbie" to "peon cadet," or whatever the next level is.
>
>I do appreciate the need to enforce rules and be consistent about it, but I
>also think that a) a warning is in order before blocking someone; b) the
>person who is being blocked should have some means of defending his/her
>actions; and c) it should always raise flags in a situation like this, when
>the person (an admin) whose deletions were reverted reported the reverts;
>and another, who only a few weeks before had lost a dispute with me, jumped
>at the opportunity to block me. I'll grant they both acted within the letter
>of the law, so to speak, but they both misbehaved - and badly. If there's a
>pattern of such misconduct over time among such admins, they shouldn't be
>admins - after all, being an admin involves a responsibility that is greater
>than being an editor, as this episode amply demonstrates.
>
>As for my "threat," it was meant earnestly. I work 60 hour weeks, am the
>parent of two kids, one of whom has special needs, and I have a long
>commute. I am doing this partly because I think it's fun and partly because
>I think it's important. I expect lots of disagreements here, and plenty of
>obnoxious, unreasonable, and ignorant people. But I also expect that the
>role of admin is taken seriously. You all don't have to be perfect, but
>there's got to be a higher standard among you; and I can safely predict that
>this whole enterprise will collapse under its own weight unless the
>responsibility of doing the right thing isn't reinforced and if necessary
>enforced. The two individuals who (probably inadvertently) colluded to block
>me should be ashamed of their actions, and I'll stand by that.
>
>All the best,
>
>Leifern
>_______________________________________________
>WikiEN-l mailing list
>WikiEN-l at Wikipedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikien-l
>
>
>


subject: [Foundation-l] Wikinews and slow servers

body:
I'd just quickly like to point out that the low output of stories on the
different Wikinews editions in the last few days is the direct result of
the recent server slowness. This is not meant as a complaint, but as an
explanation, since people are quick to judge the success of the project
by how many stories they see on any given day.

Our editors are literally queuing up to post stories, but it's very hard
to even get page views at the moment. I understand that this will change
as the 20 new servers are set up and configured. Nevertheless, this will
certainly have a substantial impact on this month's growth. C'est la vie.

Erik


from_name: Alphax

body:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ultrablue at gmail.com wrote:
> Speaking of widgets, has anybody tried coding a Wikipedia panel for
> the equivalent Deskbar thing in the upcoming release of Windows
> Longhorn? I doubt Microsoft would be so happy to promote it on their
> sites though, considering the renewed competition from Encarta.
>
> ~Mark
>

If Joy of Tech is anything to go by
(http://geekculture.com/joyoftech/joyarchives/678.html), it shouldn't be
too hard :)

Seriously: for a Windows user, I've heard surprisingly little about
Longhorn. Then again, I spend most of my time around Mac and Linux
users... maybe Longhorn will ship with Firefox, so people can just get
the Wikipedia extension?

- --
Alphax
GnuPG key: 0xF874C613 - http://tinyurl.com/8mpg9
http://en.wikipedia.org/wiki/User:Alphax
There are two kinds of people: those who say to God, 'Thy will be done,'
and those to whom God says, 'All right, then, have it your way.' - C. S.
Lewis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCf24//RxM5Ph0xhMRAijbAKCPDkFVlgOh+iWP+WvMVdgpoP371wCeJr3R
bKMOkhObitcsLgXN12h1bzU=
=KNm7
-----END PGP SIGNATURE-----


from_name: Tomer Chachamu

subject: [Wikitech-l] Human-Computer assisted editing

body:
Hello,

I had an idea where the computer makes (invents) the edits and the
human then approves them. The edits would technically be made on the
user's account (making the edit their responsibility) but the summary
would link to, say, [[User:Templatefixer]], which would link to a
website. The website would have a list (in a database) of articles to
be corrected (taken from a DB dump) and whenever somebody committed
one of these edits it would cross it off the list.

I noticed that if I don't send wpEditToken a preview is shown instead
of the edit being committed.

I would like to suggest that for 1.5 instead of the preview being
shown, the diff is shown, like pressing the "Show changes" button.

With this modification, I think I could make a PHP script for this,
with a top frame controlling things (on an external website) and the
main frame always showing something on Wikipedia. I have a rough idea
of the user interface.

This could be used for all those cases where a computer can create
suggestions but overall creates too many false positives. IMO this
could work very well to semi-automate some of the more tedious work,
such as stub sorting (where the article is shown and a list of stub
templates, but no physical typing is required) and fixing simple
punctuation errors.

Yours,
Tomer Chachamu (15)


from_name: Tim Starling

body:
Austin Hair wrote:
> Personally (and this almost always incites a riot when proposed in a
> public forum), I'd like to see MediaWiki rewritten in a language other
> than PHP, or at least have the critical parsing functions moved to
> something more efficient than calling preg_replace inside recursive
> functions (that is to say, anything).

We've already had one that was significantly slower than the regex-based
parser (JeLuF's tokenizer) and one that was about the same speed
(Waikiki). The parser we have now may well be the fastest general design
possible for native PHP. A few people have made the mistake of thinking
anything would be faster, that's clearly not true. It has to be
carefullly designed and optimised regardless of what language you write
it in.

One important thing to note is that the parser is a performance problem,
not a scalability problem. We really can throw more hardware at it, and
that will fix it quite nicely. In my opinion, our biggest performance
problem at the moment is not the parser, it's replication lag and
database load balancing. There's lots of work that has to be done there.

-- Tim Starling


from_name: David A. Desrosiers

body:
> Waaaay too slow (have you ever used Subversion?)  But it might not
> be a bad idea to put a WebDAV/DeltaV front end on whatever we create
> to make it possible for third-party tools to access it.

	Only if you're using it with the default (and horribly slow)
bdb backend. If you use fsfs, you'll see performance several orders of
magnitude faster (and it also doesn't wedge or break like bdbd does
all the time).

	http://svn.collab.net/repos/svn/trunk/notes/fsfs

David A. Desrosiers
desrod at gnu-designs.com
http://gnu-designs.com


from_name: Brion Vibber

subject: [Wikitech-l] New machines installed, killed in record 9.5 hours

body:
All the new boxen (srv11-srv30) died mysteriously while Domas and I were
trying to restart Apache after installing PHP's CURL library extension
so a proper timeout could be used on the Lucene search.

By dead, I mean "Destination Host Unreachable". They're off the network,
kaput. That _shouldn't_ happen. :) All the other machines seem just
fine; only the spanking new ones exploded, and the reason for it is not
too clear. (Freak library incompatibility -> killing machines? That
_shouldn't_ happen.)

It may be necessary for somebody to flip the switches and reboot.

-- brion vibber (brion @ pobox.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20050510/053dd5bf/attachment.pgp>


from_name: Mark Williamson

subject: [Wikipedia-l] North Frisian wikipedia - arbitrary mention

body:
Whatever success you have had, you have not indicated.

I know from experience that if people are serious, they will be
willing to work on it right away - the people who say "I may work on
it someday" or "I will work on it after so-and-so date" are the people
who end up never helping.

Regardless of who speaks it, it has been much longer than "one week",
and there has been 0 signs of activity. I don't expect a
thousand-article Wikipedia, but I think the community expects some
measure of success (at least 10 or so good articles by native
speakers) or at least one on-list endorsement by a fluent speaker (if
you have more than one, people will listen more).

It has been a long time. I think - and I'm sure the community agrees,
or feels more strict than do I - that you should withhold a request
for a North Frisian Wikipedia until you can meet at least one of the
things I've outlined above.

If these people are motivated, you should be able to get them to
support your Seeltersk request on-list, or add content to the test WP.

Mark

On 10/05/05, Wouter Steenbeek <musiqolog at hotmail.com> wrote:
> >Your "success" with Seeltersk?? Are you kidding? The Test Wikipedia
> >has 0 articles, and there is no hint of support from native speakers.
>
> Did I claim I had success in /building/ a wikipedia? I meant I had success
> in contacting scolars and, yes, in attracting native speakers. You expected
> me to have already built something, but that was too optimistic. With such a
> small language, spoken particularly by elder people, you can't expect the
> rise of a wikipedia within one week. Moreover, I was quite busy over the
> last months, and only recently the first real efforts towards building a
> Seeltersk wikipedia were done at all. If I intended tio say that I had
> success with /building/ a Seeltersk test-wp, I'd have said that.
>
>
> Wouter
>
> _________________________________________________________________
> Nieuw: Download nu MSN Messenger 7.0 http://messenger.msn.nl/
>
> _______________________________________________
> Wikipedia-l mailing list
> Wikipedia-l at Wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikipedia-l
>

--
SI HOC LEGERE SCIS NIMIVM ERVDITIONIS HABES
QVANTVM MATERIAE MATERIETVR MARMOTA MONAX SI MARMOTA MONAX MATERIAM
POSSIT MATERIARI
ESTNE VOLVMEN IN TOGA AN SOLVM TIBI LIBET ME VIDERE


body:
> It has been a long time. I think - and I'm sure the community agrees,
> or feels more strict than do I - that you should withhold a request
> for a North Frisian Wikipedia until you can meet at least one of the
> things I've outlined above.

That is, unless you attract support from native speakers on-list in
the mean time.

Mark


subject: [Wikitech-l] Our own IRC server

body:
We now have an IRC server set up, for the sole purpose of delivering
recent changes information. All discussion channels will stay at Freenode.

The problem with using Freenode was that it was hard to maintain, both
for us and for them. We had to use 10 different connections to avoid
flooding off, and if they all connected at once, the server would be K:
lined. Despite the best efforts of the Freenode staff, the exemptions
they set up were not robust, especially when the configuration changed
on either end.

With our own IRC server, we can have a single connection for all
channels. The bot is exempted from flood controls. This makes it much
easier to maintain. We can also create as many channels as we like --
one for every wiki.

We don't want to have to administer a general-purpose IRC server. That's
something Freenode does a good job of and we don't want to reproduce. So
we've patched ircd such that non-opers can't send messages to channels.
Keeping our discussion channels on another network is also useful for
coordination in the event of failure on our network.

The server hostname is irc.wikimedia.org, that's 207.142.131.229 for
those people still having DNS cache problems.

-- Tim Starling