from_name: Elisabeth Bauer

subject: [Wikipedia-l] Rethinking Meta (was- Wikiquote now has subdomains)

body:
Daniel Mayer wrote:
> --- Erik Moeller <erik_moeller at gmx.de> wrote:
>
>>This may be a good time to rethink our approach to Meta. Currently there
>>is just one big, messy Meta-Wiki, with neither particularly clear policies
>>(although my CPOV draft attempts to remedy this to some extent) nor
>>interlanguage links. Help texts are spread across the "MediaWiki User's
>>Guide" and the Help: namespace, with non-English texts in the English
>>language Help: space.

That was true a few weeks ago, but things have changed:
* Patrick is moving the complete User's guide into the help namespace
* there is a clear category system on
http://meta.wikimedia.org/Meta:Categories which permits to find the
important pages
* more cleanup ongoing

>> On the other hand, as Mav keeps pointing out, we
>>have no real community editable Wikimedia presence.
>>
>>How about a setup like this:
>>de.wikimedia.org
>>en.wikimedia.org
>>fr.wikimedia.org
>
>
> Absolutely not! We need ONE place where we can all come together. That place is
> currently meta. I'm therefore very strongly opposed to balkanizing the only
> common place we all can edit. The interface issues need to be fixed and Meta
> should be made into a truly multilingual wiki.

I agree with mav. In the german chapter we thought about setting up an
own wiki for the chapter but in the end we decided to use meta to avoid
balkanization and to facilitate cooperation.

I'd like to have a setting to switch the interface to german to make
german meta-contributors feel more at home, but there's no need for
separate wikis and zillion of translation pages.
My thoughts:
* our representation for visitors (the WMF website) should be multilingual
* the most important pages on meta should be translated (we don't have
the capacities to translate everything)
* we should accept that we need a working language (english) for wikimedia
* pages in other languages should contain english abstracts
* pages in english can have abstracts in other languages

In my opinion, it's an illusion that participation in wikimedia affairs
is possible without a basic knowledge of English. People should have the
possibility to inform themselves about the goings-on, but it makes no
sense f.e. to translate the german preparations for the Linuxtag L?rrach
into spanish. On the other hand, the spanish people should be able to
see that there are preparations done and ask the germans for experiences
and tipps for a congress in Spain. If everything was done in separate
wikis, they would probably not realize it.

greetings,
elian


list: wikitech-l

source: pipermail-mbox

from_name: Anthere

subject: [Wikitech-l] Re: HP Hardware donation

body:
Ray Saintonge wrote:
> Anthere wrote:

> Before things are shipped across the ocean, has there been any
> consideration of the effects arising from having machines designed to
> work off the European power grid put into the North American power
> grid.  The supply voltage issue can probably be overcome with
> transformers, but a differnce in the cycling of alternating current
> rates (60 cycles per second in North America) could make them useless.
> Will they even work with the same monitors as are otherwise used in
> North America?
>
> Ec

euuuuh, what a weird question ...

I brought back two computers from USA, they were fine here for several
years ;-)

of course, these were macintosh...


list: wikien-l

from_name: David Gerard

subject: [WikiEN-l] Dev request re rollback (was issues)

body:
Michael Snow wrote:

>>What's really appalling is that in many instances, not even the talk
>>page of the disputed article is being used. The only communication going
>>on is through edit summaries, and since those typically consist of "rv",
>>accusations of vandalism, snide remarks, or the pre-filled edit summary
>>from an admin using the rollback button, it's worse than useless.

If we're going to have a rollback button, I have a request: a text box
for a meaningful summary next to it. It can start filled with the
present default summary, but make it easy to make a rollback meaningful.

- d.


list: wikipedia-l

from_name: Sj

subject: [Wikipedia-l] Re: Forming an action plan for 1.0

body:
On Tue, 20 Jul 2004 00:21:11 +1000, Tim Starling
<ts4294967296 at hotmail.com> wrote:
> Sj wrote:
> > Please remember that we '''do not need developer effort''' to move towards
> > Wikipedia 1.0.
>
> Yeah I've heard that before. Coding features is vastly easier than
> organising Wikipedians. If someone puts some pretty buttons on Wikipedia
> saying things like "review this article" and "mark for concise version",
> then people will start clicking them. Policies will emerge out of the
> chaos that ensues, and everything will come together. If someone wrote
> the feature 6 months ago, we'd be ready to print by now.

I think we are in agreement -- except perhaps for your time estimate.   I note
only that non-developers have work they can do immediately to further
this project.
I had the sense that many eager people were waiting for the discussion of which
interface to implement, before working out what topics to cover, in how much
space, starting with a focus on which areas.

+sj+


from_name: Ævar Arnfjörð Bjarmason

subject: [Wikitech-l] Why OGG

body:
The flames are still quite warm at
http://en.wikipedia.org/wiki/Wikipedia_talk:Sound , take a look, you
can even grill marshmellows if you get really close to that page;)

On Wed, 21 Jul 2004 23:17:17 +0200, Gerard.Meijssen
<gerardm at myrealbox.com> wrote:
> When you want to upload on nl:wiktionary, it says that MP3 is not allowed. The reason given: http://mail.wikimedia.org/pipermail/wikien-l/2004-July/014202.html
>
> It is also suggested to use OGG in stead. I have never bothered with sound files, but it does point that OGG is the way to go.
>
> I do not know what policy is current on other wikipedia's.
>
> Thanks,
>   GerardM
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


from_name: Michael Diederich

subject: [Wikitech-l] Special:AskSQL

body:
Hi all,

today i was asking in #wikipedia to reopen the SQL-queries again for admins.
The new hardware and the low server load of SQL-queries should be a reason
to reable the most important tool of an admin.

It don't need to be on the main db-server - i could be on a slave or just
availble on low load times (1-3UTC?)..

In #wikipedia someone suggested, the option should only be granted to some
users - i also would accept that solution.

I have spoken to some de.wikipedia admins, and all of them support my
enquery.

Best regards,

da didi
--
===========================================================================
Gentoo Linux:                   Gentoo Base System version 1.5.1
kernel-2.6.7                    Pentium III (Coppermine)
===========================================================================


body:
On 07/21/04 19:56, Daniel Mayer wrote:
> --- David Gerard <fun at thingy.apana.org.au> wrote:

>>If we're going to have a rollback button, I have a request: a text box
>>for a meaningful summary next to it. It can start filled with the
>>present default summary, but make it easy to make a rollback meaningful.

> Uh - adding an extra step will make the feature much less useful. I can very
> quickly use my middle mouse button to open many tabs for each rollback. If I
> had to pause for each one and hit a button, then that would at least triple the
> amount of time it takes me to revert vandalism.

Sorry, I was using the wrong word - I mean keeping the present rollback
*link*, but adding a pre-filled edit summary box. So you can still go
zap-zap-zap-zap-zap on vandals in Firefox, but if something is clearly
a revert but could be explained as well you can fill in that.

> If admins are abusing this feature, then they should be told to knock it off
> and only use their sysop user rights to fight vandalism. Using those powers as
> a tool to use against your opponents in an edit war is not acceptable and was
> my main point with former-admin 168...

Edit wars are Bad. I swear I grit my teeth and count to three if I get
to reverting. Or try to.

- d.


list: foundation-l

from_name: Brian

subject: [Foundation-l] USPS

body:
Jimbo,

There are probably a dozen military bases in Germany, and the USPS can
be used by anyone who has access to getting on a base - that will be
your problem (military ID).

As far as Evian goes - they send it on a container ship.  It only
takes about 10-15 days to reach the states =)  You can do this with
DHL if you like, but it's still very expensive for the consumer.  Last
year I sent a 68 pound monitor to myself from San Francisco and I
believe your quote of $500 was about right (i used USPS in the end).

I will be out of the country from August 13-21 for the Olympics so
keep that in mind.  I may also be moving back to the states in
mid-September.

Brian


list: wikimedia-l

subject: [Foundation-l] USPS


body:
On Wed, 21 Jul 2004 20:27:08 +0200, Elisabeth Bauer <elian at djini.de> wrote:
> Daniel Mayer wrote:
> > --- Erik Moeller <erik_moeller at gmx.de> wrote:
> >
> >>This may be a good time to rethink our approach to Meta. Currently there
> >>is just one big, messy Meta-Wiki, with neither particularly clear policies
> >>(although my CPOV draft attempts to remedy this to some extent) nor
> >>interlanguage links.
>
> That was true a few weeks ago, but things have changed:
> * Patrick is moving the complete User's guide into the help namespace
> * there is a clear category system on
> http://meta.wikimedia.org/Meta:Categories which permits to find the
> important pages
> * more cleanup ongoing

The proportion of non-en to en text on meta is steadily increasing,
particularly since
meta-de: texts are regularly appearing, and since there is a growing group of
multilingual contributors actively translating important pages.

> > Absolutely not! We need ONE place where we can all come together. That place is
> > currently meta. I'm therefore very strongly opposed to balkanizing the only
> > common place we all can edit. The interface issues need to be fixed and Meta
> > should be made into a truly multilingual wiki.

I agree Meta should be the first place these interface issues are
fixed, even the spur
to get them fixed.  Since it has the largest concentration of
single-wiki multilingual
editors, and no history of being separated, it will be an ideal
testing grounds -- before
attempting something heroic like a merging of all wiktionary projects.

> I agree with mav. In the german chapter we thought about setting up an
> own wiki for the chapter but in the end we decided to use meta to avoid
> balkanization and to facilitate cooperation.

Thank you for this.  It is always encouraging to see a rash of german-language
edits appearing on Meta-RC, or to find a key policy-suggestion page which needs
translation *into* english.

=== On translations ===
> My thoughts:
> * our representation for visitors (the WMF website) should be multilingual
yes.

> * the most important pages on meta should be translated (we don't have
> the capacities to translate everything)
Yes. (and we will someday have the capacity; there are currently hundreds
of [[m:Translators]] with some interest in translation, and perhaps a thousand
real policy pageds on meta)

> * we should accept that we need a working language (english) for wikimedia
Perhaps someday that can be expanded to a few working languages, all of
which will be actively intertranslated?

> * pages in other languages should contain english abstracts
> * pages in english can have abstracts in other languages
Yes, I like the way this is done currently on some german pages.

> In my opinion, it's an illusion that participation in wikimedia affairs
> is possible without a basic knowledge of English. People should have the
> possibility to inform themselves about the goings-on, but it makes no
> sense f.e. to translate the german preparations for the Linuxtag L?rrach
> into spanish.

It should absolutely be possible for people to participate in wikimedia affairs
without a /good/ knowledge of English..  That this is not true today is an
artefact of where Wikimedia grew up and attracted its first editors.

As we improve the efficiency of distributing translations among many people,
and of overseeing the translation workflow (which pages translated into
how many different languages, at what level of development and with signoff
by which high-fluency proofreaders), it will become easier for people
with little
knowledge of English to contribute and participate.

>sj<


from_name: Henry H. Tan-Tenn

subject: [Wikipedia-l] Re: Attention all sysops on non-English Wikipedias

references:
<cdbks0$qar$1@sea.gmane.org>
	<a9hvbjDi1Y+AFwr7@cartref.demon.co.uk>	<a9hvbjDi1Y+AFwr7-wfA80NnNzEcG2Il/BtU0GPXRex20P6io@public.gmane.org>	<20040718050009.GB29414@jeluf.mine.nu>
	<tUayhldPjm+AFwOW@cartref.demon.co.uk>

body:
Arwel Parry wrote:

> In that case it's a rather unfortunate that there's quite a prominent
> link to it from "meta utilities" on meta's front page! But
> notwithstanding MediaWiki, there are other things which individual
> language users may wish to customise, such as magic words, words for
> "left" "right"  "centre" "thumb" etc. for the image syntax, namespace
> names, etc., which are among the things I've been trying to update on
> cy. There is still a need for user communities to be able to attract the
> attention of developers.

I have to agree.  There's also a request for the Minnan language file to
be uploaded (for the first time, so this is more than a correction of
spelling or some other small refinement).  I understand well-established
Wikipedias are generally past the point of needing to upload these
files.  And I understand developers have much more interesting ideas to
work on (say, making the hardcoded messages customizable in MediaWiki
namespace?) than doing this scut work.  But something needs to be done
so that localization efforts on smaller Wikipedias can climb out this
apparent limbo.

Having said that, I appreciate and really look forward to, having more
strings accessible via the namespace.

~~~~


from_name: sannse

body:
Yes, the mediation committee still exists.  Although both the co-chairs are
somewhat unavailable at the moment (BCorr is away and has very limited
access and I am only semi-here due to illness) other members should be
available.

I've replied on [[Wikipedia:Requests for mediation]] asking if any of you
have a preference on the mediator.

To all:

I believe the committee could do with expansion to help ensure requests are
answered as quickly as possible.   Is anyone interested in joining us?  In
general, it's probably best if any applicants are as non-controversial as
possible.

Regards

sannse

----- Original Message -----
From: "Dan Keshet" <dkesh at channel1.com>
To: <wikien-l at wikipedia.org>
Sent: Wednesday, July 21, 2004 7:33 PM
Subject: [WikiEN-l] Mediators (re: [[Israel Shahak]]

> Hi,
>
> Does the mediation committee still exist?  I know it hasn't been sitting
for
> that long, but there's a request on Wikipedia:Requests for mediation where
> all three users have requested mediation (myself, RK, Zero).  I also left
a
> note on Wikipedia talk:Mediation committee.
>
> RK is misrepresenting both myself and Zero, but I don't believe this is
the
> correct forum to discuss it.  However, if there is no prospect for
> mediation, we will have to find a forum somewhere, because [[Israel
> Shahak]] has been protected for a while and there is absolutely no sign
> that the discourse around this article is becoming more civil, let alone
> productive.
>
> --Dan
>
> _______________________________________________
> WikiEN-l mailing list
> WikiEN-l at Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikien-l


from_name: Yann Forget

subject: [Wikitech-l] Re: French hardware donation - technical choices made

body:
Hi,

Le Wednesday 21 July 2004 20:23, Bill Clark a ?crit :
> On Wed, 21 Jul 2004 20:01:49 +0200, Anthere <anthere9 at yahoo.com> wrote:
> > I do not get well this argument. Florida is not the english wiki. It is
> > OUR wiki. Improving our hardware situation is helping all of us. When
> > the servers are down, we are all down. When they are up and happy, we
> > are all happy. What is your argument to say it *help* english wikis more
> > than others ? Explain please
>
> The English Wikis use a greater portion of the available resources.
> That means the new servers would see a similar proportion of their
> resources used for serving up English pages.
>
> Or, put another way, an across-the-board 10% increase in the number of
> pages served translates into a far larger number for the English Wikis
> than anyone else.
>
> I don't really agree that it's a very good argument (after all,
> everybody would still see the same percentage performance increase)
> but it does mean that the English Wikipedia will see more absolute
> benefit from the new servers than anyone else.
>
> -Bill Clark

I think there is a misunderstanding because the European proxies will mirror
the WHOLE of the Wikimedia projects: all projects in all languages, not only
some European languages. And because many European people also read and
contribute to English projects, even if English is not their mother tongue.

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


from_name: Ilya Haykinson

subject: [Wikipedia-l] Re: Wikipedia-l Digest, Vol 12, Issue 25

body:
> Date: Wed, 21 Jul 2004 14:48:29 -0700
> From: "Jimmy (Jimbo) Wales" <jwales at wikia.com>
> Subject: [Wikipedia-l] A WikiJamSession Fantasy
> .
> .
> .
> So, I had this idea for something we could do as a part of a drive
> towards 1.0.  We could get permission from a library or libraries in
> some densely populated centers around the world to gain admission
> during a holiday or weekend that they would normally be closed.  We'd
> set up a wireless broadband network and bring together as many people
> as possible to work together day and night in a fun atmosphere to fact
> check articles and process them for final publication in a CD-ROM,
> with an eye towards print as well of course.

I think that this is a really awesome idea. Even more awesome if we
could do this on roughly the same day, in order to get some
grass-roots and formal publicity. Logistics will include getting
locations, getting good amounts of local volunteers to run the event
at each location (and handle the technical details). Perhaps we could
initially try to target some weekend in the November timeframe?

Getting libraries to open on a normal day-off might be a bit tough to
swing, but getting them to help out on a day they're open might be
easier.

-ilya haykinson


from_name: Ray Saintonge

subject: [Wikitech-l] Wikisource pages disappeared

body:
The following appeared on the [[Wikisource:Scriptorium]] (out Village Pump:

>
>     "What is Wikisource?"
>
> http://sources.wikipedia.org/wiki/Wikisource:What_is_Wikisource%3F
> Doesn't exist as of five seconds ago, according to my browser. This is
> bad, since it's linked from
> http://sources.wikipedia.org/wiki/Main_Page:English . I apologize that
> I'm a new user and don't yet know how to make intrawiki links.
> Phthoggos
> <http://sources.wikipedia.org/w/wiki.phtml?title=User:Phthoggos&action=edit>
> 04:41, 20 Jul 2004 (UTC)
>
>     The Danish and French versions (Wikisource:Hvad er Wikisource
>     <http://sources.wikipedia.org/w/wiki.phtml?title=Wikisource:Hvad_er_Wikisource&action=edit>
>     and Wikisource:Qu'est-ce que Wikisource
>     <http://sources.wikipedia.org/w/wiki.phtml?title=Wikisource:Qu%27est-ce_que_Wikisource&action=edit>)
>     are gone as well. The histories of these pages have also
>     disappeared. They don't show in the deletion log, so they have not
>     been deleted the ordinary way. I have no idea how these pages have
>     disappeared.
>
> Christian S 05:39, 20 Jul 2004 (UTC)

Has anyone been working on the software in such a way as to
inadvertently cause this problem.

Ec


from_name: Tim Starling

subject: [Wikitech-l] Re: Profiling functions and define

body:
Magnus Manske wrote:
> I vaguely remember that the profiling functions
> (wfProfileIn/wfProfileOut) use up a lot of processor time, even when empty.

I think that's a bit of an exaggeration. I just measured a time of 3.2us
per pair with it off, and 44us per pair with it on. The test was
performed on zwinger, here is the code:

<?php
require_once("commandLine.inc");
$n = 10000000;
$t = getmicrotime();

for ( $i=0; $i<$n; $i++ );

$t -= 2*getmicrotime();

for ( $i=0; $i<$n; $i++ ) {
         wfProfileIn('test');
         wfProfileOut('test');
}

$t += getmicrotime();
print $t / $n . "us/iteration\n";

function getmicrotime(){
         static $initial = false;
         list($usec, $sec) = explode(" ",microtime());
         if ( !$initial ) {
                 $initial = (float)$sec;
         }

         return ((float)$usec * 1000000 + ((int)$sec-$initial) * 1000000);
}
?>

Profile runs on the live site suggest that when switched on,
wfProfileIn() and wfProfileOut() use about 4% of execution time, so it
would follow that when switched off, they use on the order of tenths of
a percent.

By contrast Julian Ostrow, a new MediaWiki developer, is coding a
feature which will reduce to near-nothing the cost of existence test
queries, which have been observed to use up to 37% of execution time on
the live site, when the DB is under high load.

>
> I just saw the PHP "define" function, which seems to work similar to the
> C++ preprocessor #define statement.
>
> Would it be possible to "define" the profiling function names once, and
> define them as empty (or something) for running code? That would
> eliminate the need for the function call.

>
> I'm not sure that this is possible in PHP, however.

It's not. The define statement makes a constant, not a macro. In C++
terms, it's closer to "const int x=5;" than "#define X 5"

-- Tim Starling


subject: [Wikitech-l] Patent nonsense proposal

body:
Patent nonsense of course refers to the US and Japanese laws which allow software patents. Fortunately the rest of the world isn't (yet) so daft. However, before we get too caried away with banning the world's standard formats, lets consider what it involves us banning:

*JPEG (the Forgent patent, Sony paid and an unnamed comapny paid US$15 million). So, most current camera photos will be banned. I'm not yet aware of a suitable alternative, though I hope there's one. I doubt that there's one with wide enough browser support for our purpose. If you're not aware of this one, search - it'll probably be the top Google result.

*GIF of course, still royalties required in much of the world, though not the US. I assume that we'll ban something allowed in the US but encumbered elsewhere? I hope not,though - it would be foolish.

*Most video formats. JPEG, MPEG, MP4 (including DivX), Real Media, Microsofts. I'm aware of some work in this area but nothing which will meet the needs of our users for at least a year or three.

*Most fonts. Apple has patents on much of the core font hinting technology. We use fonts covered by these patents and if you've seen the alternatives, you probably won't want to switch to using them. See http://www.freetype.org/patents.html for a summary of the issues.

*Probably others - I didn't take more than a few seconds to come up with this list.

So, should we ban the most widely availabel and backwards compatible still image, audio, video and font technologies from Wikipedia?

With respect, that would be shooting ourselves in the foot.

We do need to recognise that these are the formats people have. And recognise that, however much we may like it, Windows 95 may not have support for Ogg. Libraries, schools, offices and many other places prohibit software installation without permission and we probably don't want to bar those users from our content, nor third world or poor users who may have older equipment.

We do, of course, want to encourage the use of formats which are less restricted. While doing that we should remember that it's common for patent holders to wait a decade and then spring a trap, even when they have participated in standards meetings where participants were asked to disclose their patents in advance. We do need to remember that the format we think is patent free may not be.

Rather than doing this piecemeal, lets try to find a policy we and our users can live with today, and one which encourages people to use new formats without blocking those who don't yet have those new formats. The ICANN did that yesterday. It announced the start of IPv6 support in the core DNS servers started yesterday and also said that IPv4 would be supported for about 20 years to allow a smooth transition time.

So, I propose for all encumbered formats:

*We accept and use the de facto standards, including JPEG, MP3, MPEG and Apple patented type.
*Where there is a less encumbered alternative, we encourage people to also make that available and to list the less encumbered format(s) first, to increase awareness of that format.
*Browsers send information on the formats they support. Where we have multiple formats available, we should serve the least encumbered format the client says it can support. This will involve changes to the software, which can, I hope, be done fairly slowly as we develop standards for specifying alternative forms of all multimedia works.
*Where there is a clear advantage in content or technically, we accept the encumbered format until it's clear that the vast majority (at least 99%) of users support the new format seamlesly, just as we have our target for browser support at about that level.
*Where content requires it, we support a format forever. One example is legal cases involving specific media types, where an accurate article will require the use of the exact media type used as evidence or alleged to be infringing. There's simoply no substitute for the exact file used in this sort of situation.
*When we do phase out a format, we provide a link to the old file and an archive of all such files with information about where they were used, so we don't completely lock out those who are not able to support the new format.
*When we plan to phase out a format, we give at least two yers notice and do not do so until we have alternatives available for all affected content.
*Where we are aware of external links to a specific format, we continue to make that format available for as long as the link exists.

This approach avoids failing to serve the existing clients, promotes the new formats and provides clear transition times and goals to allow resuers to adapt at a predictable pace.

I was tempted to suggest the copyleft approach: use all of the formats the US and Japanese laws encumber and not serve them in the US and Japan, to encourage people to get those nasty laws changed. I took pity on the people in those places, though.:)


subject: [Wikitech-l] Why OGG

body:
When you want to upload on nl:wiktionary, it says that MP3 is not allowed. The reason given: http://mail.wikimedia.org/pipermail/wikien-l/2004-July/014202.html

It is also suggested to use OGG in stead. I have never bothered with sound files, but it does point that OGG is the way to go.

I do not know what policy is current on other wikipedia's.

Thanks,
  GerardM


subject: [WikiEN-l] Re: Anthony and the Main Page edit war

body:
Jimmy (Jimbo) Wales wrote:
> Mark Pellegrini wrote:
>
>>Futhermore, I don't particularly like the suggestion that his actions
>>motivated policy.
>
>
> Me, too.
>

To resolve some ambiguity in my mind: Do you guys not like the
suggestion because you think it is false or because it is true?

If you think it false, consider the opening line of the renewed debate
in [[Template_talk:Feature]]:

:"In light of the heated debate/edit wars/blocking on the subject of how
articles are selected for the Main page, adhering to the concepts of
WikiLove and wishing to decrease the likelihood unfortunate incidents
occuring again, I hereby propose the revision of the de-facto rules for
the Featured Article:" (written by User:Zocky)

I don't think you could possibly ask for more concrete evidence that his
actions motivated policy change!

Pete/Pcb21


from_name: Daniel Mayer

subject:
[Foundation-l] fund drive update - why was the message removed from
	en.wikipedia?

body:
During the 8 days of the fund drive we took in an average of 855 dollars a day
for a total of $6850. But the average was trending down toward the end.

The month before the fund drive we averaged $89 a day. So I would say that the
fund drive was a big (but not huge) success.

However, why was the fund drive notice taken off of the English Wikipedia? I
thought we were going to wait until a week after Jimbo's answers were posted on
Slashdot. Since the notice was taken down our daily average plummeted to a
little more than $100 a day.

Could the notice be put back so that most cached pages will have it by the time
we get Slashdotted? Or was there a decision made somewhere that it should be
taken down?

-- Daniel Mayer

__________________________________
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
http://advision.webevents.yahoo.com/yahoo/votelifeengine/


from_name: Luc Van Oostenryck

body:
Yann Forget wrote:
>
> I think there is a misunderstanding because the European proxies will mirror
> the WHOLE of the Wikimedia projects: all projects in all languages, not only
> some European languages. And because many European people also read and
> contribute to English projects, even if English is not their mother tongue.
>
> Yann

Mmmm, are you sure this is the plan and that will be globaly efficient?

I think the best will be to use these squids for the wikis in language mostly spoken
in Europe and maybe Near-Middle-East and Africa.
And NOT use anymore the squids in Florida for these language.

But as far as I know nothing have already be decided for this.

-- Looxix


from_name: Mathias Schindler

subject: [Wikipedia-l] A WikiJamSession Fantasy

body:
Jimmy (Jimbo) Wales schrieb:

> In Berlin, I was chatting with Tim Pritlove about the annual
> Choas Communication Congress which is held in Berlin.
> http://en.wikipedia.org/wiki/Chaos_Communication_Congress
>
> This event attracts 2,500 and 3,500 participants (according to
> Wikipedia) and a central feature is the "hack center" which gives
> access to around 600 people for whatever.
>
> Not described in the Wikipedia article, but attested to by Tim
> Pritlove, it's a rocking good time.

http://meta.wikimedia.org/wiki/Wikipedia_auf_dem_21C3

I wrote a short English abstract for this site. Feel free to take part
in the discussion (English/German/whatever).

Mathias


subject: [Wikipedia-l] Waiting for 1.0

body:
On 07/21/04 21:34, Jimmy (Jimbo) Wales wrote:

> I have saved this entire thread and intend to go through it post by
> post, with pen and paper beside me, taking extensive notes, in an
> effort to generate something like a consensus from what different
> people have said.  In addition, for points that seem controversial or
> unsettled, I will try to generate a middle-of-the-road proposal of my
> own (in search of consensus), and then I'll post the whole thing here
> and on meta for feedback.

Please wait a few days! I've been thinking of little else for the past
few days and want to discuss ideas more here first.

One important point that has been I think missed here - when we talk
about 1.0 here, we're talking about the paper version, yes? I note that
your page talks about a CD release as well. But the present push is
because we have an actual paper publisher in the wings? I ask because
I've been thinking in terms of a single-volume paper concise Wikipedia,
not a CD-ROM, which could probably have all Adequate Prose on it.

> I feel that it's necessary here for me to provide some leadership and
> say "THIS is the exact proposal."  Unless I do that and submit it to a
> ratification vote so that we can get general legitimacy and acceptance
> that this is what we should do, we will continue to not-quite move
> forward.

Indeed ...

- d.


from_name: Erik Zachte

subject: [Wikipedia-l] TomeRaider 3

body:
Brian wrote:

"To anyone interested: TomeRaider 3 beta is out. It has native image, html,
and category support. I recently used user:Erik Zachte's conversion script
and the text-only database for Wikipedia is weighing in ~300MB, so including
pictures in the future may only be feasible for the wealthier of us (not
me!)"

Mat Ripley says that the new features have been designed with Wikipedia in
mind specifically. Wikipedia will become 'the flag ship' (his words) of this
popular document reader for handhelds. If it isn't already: I've had well
over 20 thousand page views on my support page for Wikipedia for TomeRaider.

My currents thoughts are to include png/gif images only. These are
relatively small and mainly consist of maps, flags and diagrams. Some jpegs
would be nice to have in thumbnail size, but I can't think of a simple
criterion which ones to include. I might add a white list opt-in feature for
people who want to run the script themselves (many do, for regular updates).

Erik Zachte


subject: [Wikipedia-l] TomeRaider 3

body:
Erik Zachte schrieb:

> Mat Ripley says that the new features have been designed with Wikipedia in
> mind specifically.

In that case, they should consider to switch to an OSI-certified free
license.

Mathias


subject: [Wikitech-l] Identifying locations, how to use many remote systems

body:
How we will use the Celeron systems in Europe hasn't been decided yet - there's still regular discussion going on in the usual technical discussion place, #mediawiki. Anyone not participating there routinely is missing a high proportion of the productive technical discussions.

The options:

1. Split by language and project. We've done this before. It's easy and well understood. It's limited when we end up having many different proxy locations because it's hard to load balance and because people in one country don't only work on one language. It's very likely that we'll do this at first, even if we change later.

2. There are several ways to identify country given an IP address. At least three anti-spam DNS servers do this and there are public lists of IP ranges by country. A very well understood solution but not one we have experience of (unless you cont me working on an open source spam blocking project which supports it). The Freenode IRC network which hosts the IRC channels uses this approach and one of their technical people likes us, was involved in developing their solution and offered asistance a few weeks ago. The information isn't perfectly accurate but it's fairly good - good enough.

3. There is at least one solution which uses internet topology analysis to determine the optimal server to send traffic to based on the IP address. It's easy enough - the routers on the internet already track this. The big advantage of this is that it will work well for any number of remote sites. When we have 50 remote sites, people will be directed to the closest one to them (and then load balancing can offload it if necessary). See http://www.supersparrow.org/ for one solution of this type.

We may well start with 1 and move to 3 later. 2 is probably worth skipping if we can - it's not as good 3 and doesn't scale to a large number of places as well. Initial tests will almost certainly use 1 for proving the concept of offloading traffic from the US based Squids and sort out any problems.

But none of this is decided yet. We won't know for a month or more, probably.


subject: [Wikitech-l] Where the technical team is from

body:
One thing people shouldn't worry about is over-emphasis on the US from the technical team. Of those whose nationality I know or have a good idea of, here's how the regularly active participants are split:

de: 4
uk: 1
fr: 2
belgium: 1
baltic states: 1
EUROPE TOTAL: 9

Australia: 2

US: 1 (plus JW and Jason who are around less than most)

We should be considerate of clear the US minority on the technical team.:)


from_name: Bill Clark

body:
On Thu, 22 Jul 2004 02:24:25 -0400, user_Jamesday
<user_jamesday at myrealbox.com> wrote:

> 1. Split by language and project.

Probably the easiest way to start.

> 2. There are several ways to identify country given an IP address.

I prefer this method, using custom-tailored DNS responses.  DNS is a
tried-and-true technology that scales sub-linearly with traffic.
Using static tables (either via BIND 9's "views" or some sort of
static route magic) is simple and well-tested.

> 3. There is at least one solution which uses internet topology analysis to determine the
> optimal server to send traffic to based on the IP address. It's easy enough - the routers
> on the internet already track this. The big advantage of this is that it will work well for any
> number of remote sites. When we have 50 remote sites, people will be directed to the
> closest one to them (and then load balancing can offload it if necessary). See
> http://www.supersparrow.org/ for one solution of this type.

Are you sure this isn't vaporware? (Version 0.0.0.0 doesn't sound very
promising to me...)

I'm also not sure how this is supposed to work... is this still a
DNS-based solution?  If so, won't it require a significant rewrite of
either portions of BIND or other nameserver software, in order to
utilize the supersparrow libraries (or their equivalent)?

> We may well start with 1 and move to 3 later. 2 is probably worth skipping if we can
> - it's not as good 3 and doesn't scale to a large number of places as well.

2 scales just fine to any number of places.  The problem with 2 is
that it relies on coarsely grained static tables to determine
topology, whereas 3 could presumably determine topology on a more
detailed level (and dynamically).

> Initial tests will almost certainly use 1 for proving the concept of offloading traffic
> from the US based Squids and sort out any problems.

That sounds sensible.

> But none of this is decided yet. We won't know for a month or more, probably.

I'll make sure to hop on the IRC channel sometime soon (I have too
much trouble multi-tasking IRC with other tasks, and I've been busy
with "real" work).

-Bill Clark


subject: [Wikitech-l] IEEE and W3C patent policy

body:
The IEEE patent policy is available at:

http://standards.ieee.org/guides/bylaws/sect6-7.html#6

The policy permits the use of patents with license fees in IEEE standards.

I'm not aware of any patents with royalties covering the MIDI format.

The W3C patent policy is far more friendly: "In order to promote the widest adoption of Web standards ... W3C will not approve a Recommendation if it is aware that Essential Claims exist which are not available on Royalty-Free terms". But that still allows non-essential itmes to require royalties. The full policy is at:
http://www.w3.org/Consortium/Patent-Policy-20040205/

Sadly, the US and Japanese software patent laws are poisoning the creative commons for the rest of the world.


from_name: Jimmy (Jimbo) Wales

subject: [Wikitech-l] Patent nonsense proposal

body:
user_Jamesday wrote:
> *JPEG (the Forgent patent, Sony paid and an unnamed comapny paid
>US$15 million).

This patent is in court right now, and very big companies are arguing
against it, including IBM, HP, and Dell.  There is good reason to
think that due to existing prior art, the patent will be invalidated.
I propose that we take a wait and see attitude on this one.

For me, the gold standard here is whether I can use a format with
legal free software.  If I can't, then we must not use it.

> *GIF of course, still royalties required in much of the world,
>though not the US. I assume that we'll ban something allowed in the US
>but encumbered elsewhere? I hope not,though - it would be foolish.

This is a moot point, since to my understandning the GIF patents have now
expired everywhere.

> *Most video formats. JPEG, MPEG, MP4 (including DivX), Real Media,
> Microsofts. I'm aware of some work in this area but nothing which
> will meet the needs of our users for at least a year or three.

We currently don't host video anyway, do we?  I think that it very
well could be that some of these will pose a problem, but before we
decide anything, we need to do some research.

The gold standard is whether I can use a format with free software.

> *Most fonts. Apple has patents on much of the core font hinting
>technology. We use fonts covered by these patents and if you've seen
>the alternatives, you probably won't want to switch to using them. See
>http://www.freetype.org/patents.html for a summary of the issues.

This is pure FUD, I'm surprised you posted it.

> So, should we ban the most widely availabel and backwards compatible
>still image, audio, video and font technologies from Wikipedia?

What you're saying, basically, is that all the major formats are
incompatible with free software (not true) and that therefore since
software freedom is impossible, we should allow anything.

I don't agree.

> We do need to recognise that these are the formats people have. And
>recognise that, however much we may like it, Windows 95 may not have
>support for Ogg.

Windows 95 supports Ogg just fine.  All the major players that people
could be using in Windows 95 support Ogg.

> *We accept and use the de facto standards, including JPEG, MP3, MPEG
>and Apple patented type.

We can use JPEG and MPEG for sure, and your point about fonts is such
nonsense that I can't even begin to respond to it.

MP3 is not possible to use in legal and free software, therefore we
will not accept it.

> *Where content requires it, we support a format forever. One example
>is legal cases involving specific media types, where an accurate
>article will require the use of the exact media type used as evidence
>or alleged to be infringing. There's simoply no substitute for the
>exact file used in this sort of situation.

There is virtually zero need for us to host an MP3 to properly illustrate
and article about the MP3 format.  This is like saying we need to host a
copy of the Harry Potter books in order to have a proper article about it.

If there *is* a compelling case for a *particular* exception to the
rule, then of course we should make that exception.  But I think this
this type of example doesn't work.

----

I don't want to give the impression that we should have a long
discussion that might or might not result in accepting the use of
formats that are so encumbered that they don't meet my gold standard.
We shouldn't, because I think there is virtually zero chance that the
community will accept anything other than my gold standard.

We can talk about particular formats and the patent situation, in an
effort to better understand what the patent situation actually is.
Let's imagine that some landmark legal case overturns the Mp3
patents... then we should have a discussion about whether that case
sufficiently unencumbers the format, etc.

But the notion that we should just accept formats because they are
widely used isn't going to fly.

--Jimbo


subject: [Wikipedia-l] Re: A WikiJamSession Fantasy

body:
Walter Vermeir wrote:
> Now there is no system to indicate that the information in a article
> is verified. And also none to make sure that correct, verified
> information is not changed at some point.

Right, that's why I had this idea (or stole it from Matthias Schindler
and the German community, it seems!  Great minds think alike!) as
being in conjunction with whatever we work out as an approval process
for a "1.0" stable release.

We've known for a long time that while the average quality of
wikipedia articles is very high, and the wide-open editing process is
integral to that, there is also a need for something we can offer to
people that meets a specific test of reliability for _all_ articles in
the stable set, not just "on average".

But I totally agree with you -- until we have a process whereby facts
that are checked stay checked :-), big sessions of fact checking and
copy editing aren't really going to be so useful.

--Jimbo


from_name: Anthony DiPierro

subject: [WikiEN-l] Re: some questions

body:
> Anthony, you are acting incredibly childishly.  If you hadn't reverted
> Danny seconds after he reverted (before he could protect) then he
> wouldn't have *had* to ask me.

I didn't realize disagreeing with whether or not a certain user was the
accepted dictator of a page *forced* two people to break pretty much every
rule about reversion (reverting without explanation, using the rollback
button on non-vandalism, protecting a page in which one is involved in a
dispute, favoring one version of a protected page over another, etc).


from_name: tic at tictric.net

body:
Am Wed, 21 Jul 2004 14:49:53 -0700 hat Jimmy (Jimbo) Wales
<jwales at wikia.com> geschrieben:

> Luc Van Oostenryck wrote:
>> I think the best will be to use these squids for the wikis in
>> language mostly spoken in Europe and maybe Near-Middle-East and
>> Africa.  And NOT use anymore the squids in Florida for these
>> language.
>
> I agree with Luc on this, but I freely admit that to me this is the
> only option realistically possible anyway, unless we have some way
> that I have not learned about to figure out where people are just by
> their ip number.

I see it regurlarly that german people are carrying IP's from other
countries depending on their service provider in my shop.
AOL for instance assigns US registered IP's to whoever they feel fit.

--Manfred

>
> --Jimbo
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l


from_name: Nikola Smolenski

subject: [Wikitech-l] HP Hardware donation

body:
On Wednesday 21 July 2004 11:58, Mathias Schindler wrote:
> Tomasz Wegrzanowski schrieb:
> > It would greatly speed up things for European users.
>
> Can you provide any data indicating that the 20ms-lag between this
> Atlantic bath tub does represent any kind of bottleneck for the average
> European user?

12  ae-0-53.mp1.London2.Level3.net (212.187.129.161)  220 ms  230 ms  200 ms
13  as-0-0.bbr2.Washington1.Level3.net (4.68.128.102)  420 ms  300 ms  300 ms

20ms indeed...


subject: [Wikitech-l] Requests related to sound files

body:
On Wednesday 21 July 2004 22:52, Mark Pellegrini wrote:
> First, for those of you who have never heard of it, the Mutopia project is
> to songs what Project Gutenberg is to text. The offer lots of public
> domain midis that are great additions to the project. In the past, I've
> converted them the hard way (tying the sound card of one computer to the
> sound card of another). I'd record it into wav, encode it as ogg, and then
> upload it.

Why not uploading the midi as well?

> (1) The 2 megabyte upload limit - I discovered through trial and error that
> uploads are capped at 2 megabytes. For full-length songs, this is way, way
> too small. A 3-4 minutes song in ogg format at average quality is about 5
> megs. I have to set my encoder to its lowest settings (0 or 1 out of 10) to
> get it under 2 megs.
>
> Angela has said (rightly so) that full length songs belong at Wikisource,
> not on Wikipedia itself. So the above changes should be made there.

If Wikipedia has full length texts of, say, national anthems, why wouldn't it
have full-length recordings of them, too?


subject: [Wikipedia-l] A WikiJamSession Fantasy

body:
Jimmy (Jimbo) Wales schrieb:

> We'd strive to have as many people as possible in one location, and to
> attract maximum media attention to what we're doing.  So the selection
> of a location would involve deliberations about keeping the cost low,
> both travel costs and hotel costs for participants travelling some
> distance.

July 19 http://meta.wikimedia.org/wiki/Wikipedia_Wissenswochenende
(including English abstract)

(historic discussions:)
June 6
http://de.wikipedia.org/wiki/Wikipedia:Qualit%E4tsoffensive/Aa/Session

April 7
http://de.wikipedia.org/w/wiki.phtml?title=Benutzer:Mathias_Schindler/DreiJahreWikipedia&diff=1302332&oldid=1029329


from_name: Walter Vermeir

body:
Jimmy (Jimbo) Wales <jwales at ...> writes:
[cut]
> So, I had this idea for something we could do as a part of a drive
> towards 1.0.  We could get permission from a library or libraries in
> some densely populated centers around the world to gain admission
> during a holiday or weekend that they would normally be closed.  We'd
> set up a wireless broadband network and bring together as many people
> as possible to work together day and night in a fun atmosphere to fact
> check articles and process them for final publication in a CD-ROM,
> with an eye towards print as well of course.

This can be fun and good for PR and community building but its usefulness is
doubtful in the current situation.

Verifying information is one thing. Making sure it is stored correctly and
stays correctly is something else.

Now there is no system to indicate that the information in a article is
verified. And also none to make sure that correct, verified information is not
changed at some point.

Off course that is the concept of Wikipedia that the community is watching the
edits and so makes sure that there is no nonsense are included.

But the point of verifying information is to make sure the information is
correct. When you put the verifyed information free again in the wild-wiki you
have increased the general likelihood that the information is correct but you
do not get really a trustworthy encyclopedia.

Also the idea of voting for articles will only increase the general quality of
Wikipedia but not really get trustworthy articles.

How to do it i do not know. But making a big efford in verifying seems a waste
of work in the current setup.

I do have a idea for a temporary solution.

Create a "Fact Sheet"-option. A option to attach a special page the contains
verifyed basic information to a article. It should be in a form format. Whit a
drop-down menu where you select the profile of the subject and fields for
specific indisputable facts.

This should be done by the person who has done the verification of the
information. Because it should be absolute correct information and to guaranty
that the information stays correct modifying should only be possible by the
original verificator. If not there is no point of creating the fact sheet.

That verificator (senior-Wikipedians only?) will connect his good name and
reputation to the information in the fact sheet.

Off course there can always be a discussion about it and somebody should be
abel to overrule the verificator but that should be a rare exception.

Whit this system you still do not have a system for getting a realy trustworthy
article but you have at least the possibility for puting the most basic
information save so you can check easy something like of it is true that the
Zeppelin Hindenburg exploded on 6 may 1937. It is a step to a verified
wikipedia.

Changing the software for this is a lot of work. But looking up information
because you need to be sure also.

---
[[wikipedia:nl:gebruiker:walter]]


subject:
[Foundation-l] fund drive update - why was the message removed
	from en.wikipedia?

body:
I will try to find out when my answers will be posted, so that we can
be prepared a couple of hours in advance.

Angela_ wrote:
> As it was only supposed to be a temporary measure, there is no reason
> for it currently to be up. However, perhaps we should consider whether
> it needs to be a more permanent measure. If the notice is bringing in
> significantly more donations than we normally get, should it be there
> permanently, and just made more prominent during the fundraising
> drives?

In this regard, it is important to remember that if we can balance the
intrusiveness/tackiness of the notice properly against the usefulness
of the money that it brings in, we will have a steadier revenue stream
and not need to rely on "crisis" fundraising calls as much.

I think what we should do is move the notice toward the bottom of the
page, and have it read something like this: "If you found this article
or other Wikipedia articles to be useful to you, please visit our
donation page to find out how you can help support the
nonprofit Wikimedia Foundation."

It will be less prominent there, but I think highly effective.  Even
if it brings in less month than a top-page notice, it will likely
bring in enough that we can delay much longer between major begging.

--Jimbo


subject:
[Foundation-l] Projekt GALILEO (Wikipedia with Geographical
	information)

body:
Jakob Voss wrote:
> * We need the cooperation of Wikimedia Foundation and the community

Just tell me what you need of me, and I will do my best.  However, I
am going out of town Saturday for 1 week, and I am unsure as to how
much access to the net I will have.  Hopefully Angela and Anthere can
take up the slack on behalf of the foundation.

--Jimbo


subject:
[Foundation-l] fund drive update - why was the message
	removed from en.wikipedia?

body:
--- Angela_ <beesley at gmail.com> wrote:
> On Thu, 22 Jul 2004 09:27:54 -0700, Jimmy (Jimbo) Wales
> <jwales at wikia.com> wrote:
> > I think what we should do is move the notice toward the bottom of the
> > page, and have it read something like this: "If you found this article
> > or other Wikipedia articles to be useful to you, please visit our
> > donation page to find out how you can help support the
> > nonprofit Wikimedia Foundation."
>
> This could be added to [[MediaWiki:Lastmodified]]. I've put a message
> at [[MediaWiki talk:Lastmodified]] to check there are no strong
> objections and will add the message there if there aren't. See
> http://simple.wikipedia.org/ for an example of the message in use.

That just obscures the *very* important copyright and disclaimer info.

If we are going to have a fund drive we really need to have notices up that
people can't miss. They will be taken down when the fund drive is over.

-- mav

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail


from_name: Fennec Foxen

subject: [WikiEN-l] Re: some questions

body:
On Thu, 22 Jul 2004 06:23:44 -0400, Anthony DiPierro
<anthonydipierro at hotmail.com> wrote:
> I didn't realize disagreeing with whether or not a certain user was the
> accepted dictator of a page *forced* two people to break pretty much every
> rule about reversion (reverting without explanation, using the rollback
> button on non-vandalism, protecting a page in which one is involved in a
> dispute, favoring one version of a protected page over another, etc).

Anthony, when you learn to disagree with policies through techniques
other than edit wars, then maybe people will listen to you if you ever
talk about being FORCED into them.


from_name: Ashar Voultoiz

subject: [Wikipedia-l] Re: IBM wiki history visualization tool

body:
Fennec Foxen wrote:
> Some of us have seen this:
> http://researchweb.watson.ibm.com/history/
>
> Some have not. It's cool, and it's about us. What's cooler is the
> response to my message sent about a few trivial things on the website
> and a query or two:
>
>>Thanks for the notes... I am working on updating the web site and will
>>incorporate your suggestions. I'm also working on getting clearance to
>>release the "history flow" tool!

Hopefully the tool will be a GPL software and we will be able to include
  it directly in mediawiki !  :o)

--
Ashar Voultoiz


body:
--- "Jimmy (Jimbo) Wales" <jwales at wikia.com> wrote:
>....
> It will be less prominent there, but I think highly effective.  Even
> if it brings in less month than a top-page notice, it will likely
> bring in enough that we can delay much longer between major begging.

There is nothing wrong with quarterly fund drives and having the message up
constantly will just mean that people will tend to tune it out. This is
*especially* true if it is at the bottom of pages.

Thus periodic messages in parts of a page that can't be ignored will generate
the biggest response.

These fund drives could also be coordinated with press releases, meet-ups, jam
sessions, WikiReader distribution, quarterly foundation meetings and other
special events clustered around certain weeks each quarter.

-- Daniel Mayer

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail


body:
Nikola Smolenski wrote:

>On Wednesday 21 July 2004 22:52, Mark Pellegrini wrote:
>
>
>>First, for those of you who have never heard of it, the Mutopia project is
>>to songs what Project Gutenberg is to text. The offer lots of public
>>domain midis that are great additions to the project.
>>
>>
>Why not uploading the midi as well?
>
>
>>Angela has said (rightly so) that full length songs belong at Wikisource,
>>not on Wikipedia itself. So the above changes should be made there.
>>
>>
>
>If Wikipedia has full length texts of, say, national anthems, why wouldn't it
>have full-length recordings of them, too?
>
I have no particular objection to having an archive of this sort in
Wikisource.  One still has to be mindful of copyright issues.  I am not
aware of anyone trying to enforce copyrights on the words and musical
score of a national anthem.  Recordings add another dimension in that
performance rights may involve additional copyrights.  Copyright issues
are a big concern at Wikisource, and the onus should be on the person
contributing something to justify his claims that he has the right to
upload something.  Verifying this for someone else can be a difficult job.

I have visited some general national anthem sites, and it seems that
someone just plugged in the notes on the score into a computer program.
The musical quality is just bloody awful.  Whatever is done, I sincerely
hope that it sounds better than some of these excuses for music. :-)

Ec


body:
Neil Harris wrote:
> That's excellent! Is there currently a colo in Europe, or someone
> willing to host one? If there isn't one, perhaps we should consider
> where is
> a) cheapest to buy colocation   (or find a donor?)
> b) cheapest to buy bandwidth   (or find a donor?)
> c) best-connected to the rest of Europe?
>
> At the moment, I would imagine the best candidates to be London or
> Amsterdam.
>
> -- Neil

For c) point, the biggest european countries internet wise are really
well connected. Just restrict to De / Fr / Nl / Uk. Other countries
might be less connected (aka Es, Cz, Ee).

Also lot of ISPs just got their transatlantic links connected to London,
while NL is really the central place of the european internet.

--
Ashar Voultoiz


references:
<1090420006.a621479cuser_Jamesday@myrealbox.com>	<40FE85A9.5040602@tonal.clara.co.uk>
	<cdnuvh$atc$1@sea.gmane.org>

body:
Ashar Voultoiz wrote:

> Neil Harris wrote:
>
>> That's excellent! Is there currently a colo in Europe, or someone
>> willing to host one? If there isn't one, perhaps we should consider
>> where is
>>
>> At the moment, I would imagine the best candidates to be London or
>> Amsterdam.
>
> For c) point, the biggest european countries internet wise are really
> well connected. Just restrict to De / Fr / Nl / Uk. Other countries
> might be less connected (aka Es, Cz, Ee).
>
> Also lot of ISPs just got their transatlantic links connected to
> London, while NL is really the central place of the european internet.

If the idea of European colo were being pursued, one in the UK would not
be recommended.  Doing so would tend to reinforce the view that this is
an English language dominated venture.

Ec


from_name: Gutza

subject: [Wikitech-l] Patent nonsense proposal

body:
About still formats, why not use PNG? It does hold some restrictions,
depending on your building method
(http://www.libpng.org/pub/png/pngfaq.html#patents), but it should be
pretty much safe if we can arrange automatically converting whatever
format the user uploads to the "proper" (i.e. free) PNG format.

--Gutza

user_Jamesday wrote:

>Patent nonsense of course refers to the US and Japanese laws which allow software patents. Fortunately the rest of the world isn't (yet) so daft. However, before we get too caried away with banning the world's standard formats, lets consider what it involves us banning:
>
>*JPEG (the Forgent patent, Sony paid and an unnamed comapny paid US$15 million). So, most current camera photos will be banned. I'm not yet aware of a suitable alternative, though I hope there's one. I doubt that there's one with wide enough browser support for our purpose. If you're not aware of this one, search - it'll probably be the top Google result.
>
>*GIF of course, still royalties required in much of the world, though not the US. I assume that we'll ban something allowed in the US but encumbered elsewhere? I hope not,though - it would be foolish.
>
>*Most video formats. JPEG, MPEG, MP4 (including DivX), Real Media, Microsofts. I'm aware of some work in this area but nothing which will meet the needs of our users for at least a year or three.
>
>*Most fonts. Apple has patents on much of the core font hinting technology. We use fonts covered by these patents and if you've seen the alternatives, you probably won't want to switch to using them. See http://www.freetype.org/patents.html for a summary of the issues.
>
>*Probably others - I didn't take more than a few seconds to come up with this list.
>
>So, should we ban the most widely availabel and backwards compatible still image, audio, video and font technologies from Wikipedia?
>
>With respect, that would be shooting ourselves in the foot.
>
>We do need to recognise that these are the formats people have. And recognise that, however much we may like it, Windows 95 may not have support for Ogg. Libraries, schools, offices and many other places prohibit software installation without permission and we probably don't want to bar those users from our content, nor third world or poor users who may have older equipment.
>
>We do, of course, want to encourage the use of formats which are less restricted. While doing that we should remember that it's common for patent holders to wait a decade and then spring a trap, even when they have participated in standards meetings where participants were asked to disclose their patents in advance. We do need to remember that the format we think is patent free may not be.
>
>Rather than doing this piecemeal, lets try to find a policy we and our users can live with today, and one which encourages people to use new formats without blocking those who don't yet have those new formats. The ICANN did that yesterday. It announced the start of IPv6 support in the core DNS servers started yesterday and also said that IPv4 would be supported for about 20 years to allow a smooth transition time.
>
>So, I propose for all encumbered formats:
>
>*We accept and use the de facto standards, including JPEG, MP3, MPEG and Apple patented type.
>*Where there is a less encumbered alternative, we encourage people to also make that available and to list the less encumbered format(s) first, to increase awareness of that format.
>*Browsers send information on the formats they support. Where we have multiple formats available, we should serve the least encumbered format the client says it can support. This will involve changes to the software, which can, I hope, be done fairly slowly as we develop standards for specifying alternative forms of all multimedia works.
>*Where there is a clear advantage in content or technically, we accept the encumbered format until it's clear that the vast majority (at least 99%) of users support the new format seamlesly, just as we have our target for browser support at about that level.
>*Where content requires it, we support a format forever. One example is legal cases involving specific media types, where an accurate article will require the use of the exact media type used as evidence or alleged to be infringing. There's simoply no substitute for the exact file used in this sort of situation.
>*When we do phase out a format, we provide a link to the old file and an archive of all such files with information about where they were used, so we don't completely lock out those who are not able to support the new format.
>*When we plan to phase out a format, we give at least two yers notice and do not do so until we have alternatives available for all affected content.
>*Where we are aware of external links to a specific format, we continue to make that format available for as long as the link exists.
>
>This approach avoids failing to serve the existing clients, promotes the new formats and provides clear transition times and goals to allow resuers to adapt at a predictable pace.
>
>I was tempted to suggest the copyleft approach: use all of the formats the US and Japanese laws encumber and not serve them in the US and Japan, to encourage people to get those nasty laws changed. I took pity on the people in those places, though.:)
>
>_______________________________________________
>Wikitech-l mailing list
>Wikitech-l at wikimedia.org
>http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>
>
>


from_name: Jakob Voss

subject:
[Foundation-l] Re: Rethinking Meta (was- Wikiquote now has
	subdomains)

body:
Daniel Mayer wrote:

 > Meta in *particular* is there for multiproject and multilingual
 > coordination. How is that coordination going to happen on separate
 > wikis?

Ray Saintonge wrote:

 > I too oppose balkanization of Meta and other projects.  People would
 > certainly feel more at ease working in their own language groups, but
 > always at the risk of not seeing what others are doing.  Once the
 > languages are separated there would never be any incentive to get
them > back together again, even if the right software were developed.

Full ack. The German Wikimedia Association settled at meta and not at
de.wikipedia because we do not want to be seperated. We startet to write
short abstracts for german pages at meta. Naming problems can be solved.
For instance [[Merchandising]] could point to [[Merchandising (en)]] and
[[Merchandising (de)]]. What is missing is the possibility to change the
interface's language but not dividing the pages.

Jakob


body:
Daniel Mayer wrote:
> There is nothing wrong with quarterly fund drives and having the
> message up constantly will just mean that people will tend to tune
> it out. This is *especially* true if it is at the bottom of pages.
> Thus periodic messages in parts of a page that can't be ignored will
> generate the biggest response.

I see your point, but isn't this an empirical question?  I'm not at
all confident that it is actually true that our greatest total revenue
would come in that way, and also of course, maximizing revenue isn't
the goal, but rather something like 'getting enough revenue to do what
we want to do, without being too annoying and tacky'.

--Jimbo


subject: [Wikitech-l] Re: Wikisource pages disappeared

body:
Tim Starling wrote:

> Ray Saintonge wrote:
>
>> The following appeared on the [[Wikisource:Scriptorium]] (our Village
>> Pump):
>>
>>>     "What is Wikisource?"
>>>
>>> http://sources.wikipedia.org/wiki/Wikisource:What_is_Wikisource%3F
>>> Doesn't exist as of five seconds ago, according to my browser.
>>
> This is an old escaping problem rearing its ugly head yet again. It
> should be fixed soon. Note that the page exists, as does its history,
> it's just the rewrite rule for /wiki/ pages that is broken. You can
> reassure yourself by viewing it with the following URL:
>
> http://sources.wikipedia.org/w/wiki.phtml?title=Wikisource:What_is_Wikisource%3F

Thanks for your help, Tim.

I always feel diminished when I need to seek help from a higher power to
get something like this fixed.  Is there a better way for us ordinary
mortals to deal with this kind of problem?  When a question is raised by
another user I prefer attempting to answer it to the best of my
abilities, but often those abilities are insufficient to the task.

Would a "Bug report patrol" be a useful idea?  In this all developers
together would divide the task of patrolling the bug reports on all the
Wikis where they would attempt to deal with the questions that are
raised there.  In many cases a simple answer to a person's question may
be the only thing needed. In the more intractable situations it may give
rise to a "Super-bug report page" that is circulated among the
developers.  I know of the recommendation to put things on Sourceforge,
but to many people that opens new problems around dealing with the
culture of an entirely different site.

 From what I've seen of bug report pages, the material that is there
often stays a long time and leaves the impression that nobody is looking
at it.

Ec


from_name: Claudio V

subject: [Wikitech-l] Update to 1.3 beta 4 failed

body:
Michael:

I believe you are suppose to run the installation
process of version 1.3 Beta because just over writting
the media wiki with the new version won't work.  Once
you process the new version it will change some tables
of the database and you will not have that problem
again.

Claudio

--- "Micha?l_P." <mytechos at altern.org> wrote: >
> Hi,
>
> I decompressed the tgz in my installation of the
> previous version
> of media wiki (a 1.2.6). The site still works and
> has the new
> template.
>
> But when I try to login, I get the following error:
>
>   A database query syntax error has occurred. This
> could be
> because of an illegal search query (see Searching
> All4dev), or it
> may indicate a bug in the software. The last
> attempted database
> query was:
>
>      SELECT
>
user_name,user_password,user_newpassword,user_email,user_real_name,user_options,user_rights,user_touched
>
> FROM user WHERE user_id=2
>
> from within function "User::loadFromDatabase". MySQL
> returned
> error "1054: Unknown column 'user_real_name' in
> 'field list'".
>
>
> Obviously the database didn't update. And I don't
> know how to
> update it manually. BTW, the help page about
> updating is totally
> useless:
>
http://meta.wikimedia.org/wiki/Upgrade_from_1.2_to_1.3
>
> Thanks in advance
>
>
> --
> Micha?l P.
> gpg:        D4C8 F73D A000 71C7 44EF  27E6 8982 4991
> 7126 3CE3
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
>
http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>

______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca


subject: [Wikitech-l] Re: Patent nonsense proposal

references:
<1090466195.d66a863cuser_Jamesday@myrealbox.com>	<40FF714E.5060609@moongate.ro>
	<cdod61$gsr$1@sea.gmane.org> <40FFCEE4.7080207@moongate.ro>

body:
On Thu, 22 Jul 2004 17:27:48 +0300, Gutza <gutza at moongate.ro> wrote:
> That's true, but it can happily replace GIF's, it's actually smaller if
> compared on par (8-bit images).

Yes. Both PNG and GIF are lossless, and you can convert between them
until the [[You have two cows|cows]] come home. Also, PNG compression
is highly variable- you can generally compress an image better with
PNG than with GIF, easily, if you tweak your compression (instead of
accepting some 24-bit low-compression default). If you REALLY want to
make a crack at it, run pngcrush or something similar with insane
try-and-try-again compression. When the PNG is bigger, you're usually
talking of file sizes too small to matter much anyway. :)


from_name: Yann Forget

subject: [Wikitech-l] Patent nonsense proposal

body:
Hi,

Le Thursday 22 July 2004 05:16, user_Jamesday a ?crit :
>
> *GIF of course, still royalties required in much of the world, though not
> the US. I assume that we'll ban something allowed in the US but encumbered
> elsewhere? I hope not,though - it would be foolish.

I think this is not true any more. All patents about GIF have expired. cf.
http://www.unisys.com/about__unisys/lzw
There was a discussion recently about this, isn't?

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


body:
You are not allowed to post to this mailing list, and your message has
been automatically rejected.  If you think that your messages are
being rejected in error, contact the mailing list owner at
foundation-l-owner at wikimedia.org.

Subject:
Projekt GALILEO (Wikipedia with Geographical information)
From:
Jakob Voss <gmane-user at nichtich.de>
Date:
Thu, 22 Jul 2004 11:39:52 +0200
To:
foundation-l at wikipedia.org, wikide-l at wikipedia.org, vorstand at wikimedia.de

Hi,

As some of you already may have noticed there is the "First European
Idea Competition of the Satellite Navigation" called "GALILEO Masters
2004" [1]. Stefan Richter announced the idea to participate. Only
european companies are allowed so Wikimedia Germany or freiheit.com [2]
(the company where Stefan Richter works) would apply. Deadline is Friday
the 30th of this month. To participate you have to fill in a
questionaire [3] and you may add up to two images.

We already have most of the proposal and a discussion with collections
of ideas [4] - the latter mostly in German but the proposal is the most
important.

Missing tasks:

* We need the cooperation of Wikimedia Foundation and the community
* Who should participate (the competition is aimed to small companies so
maybe freiheit.com would be good choice for a cooperation)?
* Formulating the missing answers
* Perfecting all the answers
* Two images for demonstration purpose (I drew [5] but some fictious
screenshots may be more suasive)
* Summarizing and translating the discussion and the ideas (mainly for
us and later)

Everybody is invited to participate until next wendsday (deadline).
Please try to seperate discussion and proposals or summaries. We should
have a conclusive concept before starting to implement anything. I am
sure that we will have the most useful database of free annotated
geographical data in two years! There are applications most of the
normal internet or encyclopedia reader has not even dreamed of. Let's go
for it!

Jakob

[1] http://www.galileo-masters.com
[2] http://www.freiheit.com
[3] http://meta.wikimedia.org/wiki/GALILEO_Masters_2004/Questionaire
[4] http://meta.wikimedia.org/wiki/Talk:GALILEO_Masters_2004
[5] http://meta.wikimedia.org/wiki/Image:GALILEOArchitecture.png


body:
Hi,

As some of you already may have noticed there is the "First European
Idea Competition of the Satellite Navigation" called "GALILEO Masters
2004" [1]. Stefan Richter announced the idea to participate. Only
european companies are allowed so Wikimedia Germany or freiheit.com [2]
(the company where Stefan Richter works) would apply. Deadline is Friday
the 30th of this month. To participate you have to fill in a
questionaire [3] and you may add up to two images.

We already have most of the proposal and a discussion with collections
of ideas [4] - the latter mostly in German but the proposal is the most
important.

Missing tasks:

* We need the cooperation of Wikimedia Foundation and the community
* Who should participate (the competition is aimed to small companies so
maybe freiheit.com would be good choice for a cooperation)?
* Formulating the missing answers
* Perfecting all the answers
* Two images for demonstration purpose (I drew [5] but some fictious
screenshots may be more suasive)
* Summarizing and translating the discussion and the ideas (mainly for
us and later)

Everybody is invited to participate until next wendsday (deadline).
Please try to seperate discussion and proposals or summaries. We should
have a conclusive concept before starting to implement anything. I am
sure that we will have the most useful database of free annotated
geographical data in two years! There are applications most of the
normal internet or encyclopedia reader has not even dreamed of. Let's go
for it!

Jakob

[1] http://www.galileo-masters.com
[2] http://www.freiheit.com
[3] http://meta.wikimedia.org/wiki/GALILEO_Masters_2004/Questionaire
[4] http://meta.wikimedia.org/wiki/Talk:GALILEO_Masters_2004
[5] http://meta.wikimedia.org/wiki/Image:GALILEOArchitecture.png


from_name: Brion Vibber

body:
Ray Saintonge wrote:
>  From what I've seen of bug report pages, the material that is there
> often stays a long time and leaves the impression that nobody is looking
> at it.

That it stays a long time is *exactly* why things need to be reported
there. Problem reports on wiki pages get lost and forgotten.

-- 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/20040722/fd9a70f6/attachment.pgp>


subject: [Wikitech-l] Re: French hardware donation - technical choices made

body:
Le Wednesday 21 July 2004 23:11, Jimmy (Jimbo) Wales a ?crit :
> > I think there is a misunderstanding because the European proxies
> > will mirror the WHOLE of the Wikimedia projects: all projects in all
> > languages, not only some European languages. And because many
> > European people also read and contribute to English projects, even
> > if English is not their mother tongue.
>
> That sounds excellent, but isn't that technically difficult?  Maybe
> I've missed some discussion of how to do this.

I was refering to the point 3 in this:
http://mail.wikipedia.org/pipermail/wikitech-l/2004-July/011452.html

> --Jimbo

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


from_name: Daniel Mayer

body:
--- "Jimmy (Jimbo) Wales" <jwales at wikia.com> wrote:
> I see your point, but isn't this an empirical question?  I'm not at
> all confident that it is actually true that our greatest total revenue
> would come in that way, and also of course, maximizing revenue isn't
> the goal, but rather something like 'getting enough revenue to do what
> we want to do, without being too annoying and tacky'.

That is why we would create special events to coincide with fund drives. This
would limit the display of the fund drive notice to 4 weeks a year - one each
quarter. We would have certain goals to attain during that week and special
events to get people excited (a combination of meet-ups/face-to-face board
meetings, jam sessions, WikiReader work, and press releases).

I think that will be far more effective than having a constant message.

-- Daniel Mayer

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


from_name: Neil Harris

body:
Jimmy (Jimbo) Wales wrote:

>>I think there is a misunderstanding because the European proxies
>>will mirror the WHOLE of the Wikimedia projects: all projects in all
>>languages, not only some European languages. And because many
>>European people also read and contribute to English projects, even
>>if English is not their mother tongue.
>>
>>
>
>That sounds excellent, but isn't that technically difficult?  Maybe
>I've missed some discussion of how to do this.
>
>It's easy to fix it so that fr, es, de, are all routed through the
>European squid proxies: we just point the dns entries at the new ip
>numbers for the French squid cluster, no problem.
>
>It's much harder (right?) to identify where a user is coming from and
>route them through the proxy that's best for them.  This is what
>Akamai and people like this charge big bucks for doing.
>
>Or, is there a free (or cheap) way to approximate that?
>
>--Jimbo
>
>

== IP --> location mapping ==

The key thing here is that we don't need to be very accurate, providing
we are reasonably consistent.

The simplest way to handle things is to assume that all RIPE-registered
IP addresses are somewhere in Europe, and all other addresses (ARIN,
APNIC,. LACNIC...) are somewhere else "nearer" the US. Then we can use
Wikimedia's own DNS servers to serve different lists of server IP
addresses depending on the source network of the request.

IANA allocate /8 blocks of IP addresses to the regional registries, and
maintain a helpful up-to-date machine-readable list at
http://www.iana.org/assignments/ipv4-address-space

That will probably get you 80%-90% of the goodness of a commercial solution.

For another alternative, you might want to look at
http://countries.nerd.dk/ which seems to be taken from more fine-grained
inspecting of registry data.

== Serving the DNS responses ==

I'm still not sure about what the best way is to do this. Running a
couple of instances of BIND on different ports on the authoritative
servers for wikipedia.org and doing reverse-NAT based on source
addresses for packets that arrive on port 53 is a crude way of doing
things, but it's the first that comes to mind.

Another is to hack an existing small DNS server implementation: unless
someone has done it already?

-- Neil


from_name: Matt Brown

subject: [WikiEN-l] Re: Dev request re rollback (was issues)

body:
On Thu, 22 Jul 2004 20:43:19 +0200, Anthere <anthere9 at yahoo.com> wrote:
> It is not a rule, but I think it is best that sysops should not use
> power they have in disagreement with other users who do not have that
> power. Yes, both can do revert, but using the rollback feature is
> perceived as a "power".

The problem with rollback is the dismissiveness of it, for one thing
-- it's fundamentally treating an addition 'as vandalism' - not even
worth a comment as to why it's removed.  Though that's no worse than
just entering 'rv' or 'revert' as the comment.

The other problem with rollback is it reverts not just the most recent
change, but rather rolls back to the last edit by another user.  This
means if you're using it on non vandalism, it's possible to
accidentally roll back too far.

-Matt (User:Morven)


body:
Bill Clark wrote:

>On Wed, 21 Jul 2004 18:13:05 -0400, Bill Clark <wclarkxoom at gmail.com> wrote:
>
>
>
>>Here's the full breakdown:
>>
>>http://spamid.servebeer.com:8081/utils/include/spamid/registry_mappings.jsp
>>
>>
>
>...and here's how to implement the proposed geographic load balancing in BIND:
>
>http://sysadmin.oreilly.com/news/views_0501.html
>
>-Bill Clark
>
>
>
Ah. That's nifty. Now all we need is a "master" global zone file, with a
perl or python cron job that uses the geo-data to munch this into a set
of sorted zone files, one for each geographic region, as well as a
matching bind.conf with the views information in it, and kicks bind to
restart it every day keep up to date with changes in the reference file.

-- Neil


body:
Ashar Voultoiz wrote:

> Neil Harris wrote:
>
>> That's excellent! Is there currently a colo in Europe, or someone
>> willing to host one? If there isn't one, perhaps we should consider
>> where is
>> a) cheapest to buy colocation   (or find a donor?)
>> b) cheapest to buy bandwidth   (or find a donor?)
>> c) best-connected to the rest of Europe?
>>
>> At the moment, I would imagine the best candidates to be London or
>> Amsterdam.
>>
>> -- Neil
>
>
> For c) point, the biggest european countries internet wise are really
> well connected. Just restrict to De / Fr / Nl / Uk. Other countries
> might be less connected (aka Es, Cz, Ee).
>
> Also lot of ISPs just got their transatlantic links connected to
> London, while NL is really the central place of the european internet.
>
Hence my choice of London and NL. There's plenty of capacity between the
two, as well.

-- Neil


from_name: Timwi

subject: [Wikitech-l] Re: Requests related to sound files

body:
Tim Starling wrote:

> I've raised the limit site-wide to 5 MB.

Why do we need a technically enforced upload limit at all? Why can't we
leave the decision on whether to keep a large file or not to the
respective wiki community?


body:
Gutza wrote:

> About still formats, why not use PNG? It does hold some restrictions,
> depending on your building method
> (http://www.libpng.org/pub/png/pngfaq.html#patents), but it should be
> pretty much safe if we can arrange automatically converting whatever
> format the user uploads to the "proper" (i.e. free) PNG format.

PNG is unsuitable for continuous-tone graphics.

By "unsuitable" I mean its compression isn't much better than BMP.

Timwi


from_name: Ricky Beam

body:
On Wed, 21 Jul 2004, Jimmy (Jimbo) Wales wrote:
...
>That sounds excellent, but isn't that technically difficult? ...
...
>It's much harder (right?) to identify where a user is coming from and
>route them through the proxy that's best for them.  This is what
>Akamai and people like this charge big bucks for doing.

Ok.  Others have commented on this (and at least one has done some
homework), but as one who has done this sort of thing (*is* doing this
sort of thing) and knows first hand how Akamai's magic works, I'm gonna
unmuddy the waters a bit...

First, difficulty is open to discussion.  It's rather simple to configure
"views" within BIND.  It becomes a management hassle on the scale being
proposed, but it's still very much doable.

Identifying the physical location of a user will never be 100% accurate.
And technically, it doesn't matter where they *physically* are; the ip
layer path between them and any farm(s) is the only important part.  One
can assume IANA address deligations are going to fall within the correct
region.  However, we all know this is not always the case.  It'll have
to do.  (the more accurate alternative(s) are a nightmare of complexity.)

Akamai's foo (and yes, I'm literally wearing an Akamai hat *grin*) is
based mostly on the localized caches.  Each ISP hosting a cache has reported
their announced address space to Akamai which is used to aim requests
to the local cache(s).  If your IP isn't covered by a local cache, you'll
be aimed to a "close" public cache.  For example, if you ask one of BTI's
dns servers for an akadns host, you'll get back a bti address for one of
the cache servers on the edge of their network. (because akamai will see
the request coming from within bti's network.)

 ===

In short, this can be done.  It'll take a bit of tweaking to get a happy
balance.  And it'll require some maintenance, but what doesn't around
here :-)

--Ricky

PS: For my money, grab that 16GB beast and beg nforce.nl to host it for us.
    It'd make a nice memcache and fileserver.


from_name: Bill Clark

body:
On Thu, 22 Jul 2004 14:01:21 -0400 (EDT), Ricky Beam
<jfbeam at bluetronic.net> wrote:

> First, difficulty is open to discussion.  It's rather simple to configure
> "views" within BIND.  It becomes a management hassle on the scale being
> proposed, but it's still very much doable.

user_Jamesday pointed out another solution using the Supersparrow
libraries, which I initially poo-pood as potential vaporware but upon
further investigation find to be rather interesting.

They have a patch for BIND9 that allows some BGP-type magic to happen
as a replacement for views, which should improve the capabilities of
such a system tremendously.

I got it mostly installed (their patch for BIND9 was broken, but
mostly easily fixed, although I'm still having a few problems I
probably won't have the time to sort out until after this weekend...
going to a wedding).

They also have an implementation that uses the Dents nameserver, but
I'm not familiar with that so I don't know if that's useful at all.

-Bill Clark


subject: [Wikitech-l] MediaWiki 1.3.0beta5 released

body:
Contains accumulated bug fixes since the last beta. Hopefully this
should resolve most major upgrade and installation issues (missing
user_real_name field, PEAR error with bad temp dir).

Release notes:
https://sourceforge.net/project/shownotes.php?release_id=255101

Download:
http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.3.0beta5.tar.gz?download

Report bugs at:
https://sourceforge.net/tracker/?group_id=34373&atid=411192

Play "Stump the Developers" live on IRC:
#mediawiki on irc.freenode.net

Help mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

-- 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/20040722/c3cb88d7/attachment.pgp>


subject: [Wikitech-l] [Mediawiki-l] MediaWiki 1.3.0beta5 released

body:
Contains accumulated bug fixes since the last beta. Hopefully this
should resolve most major upgrade and installation issues (missing
user_real_name field, PEAR error with bad temp dir).

Release notes:
https://sourceforge.net/project/shownotes.php?release_id=255101

Download:
http://prdownloads.sourceforge.net/wikipedia/mediawiki-1.3.0beta5.tar.gz?download

Report bugs at:
https://sourceforge.net/tracker/?group_id=34373&atid=411192

Play "Stump the Developers" live on IRC:
#mediawiki on irc.freenode.net

Help mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l

-- 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/20040722/c3cb88d7/attachment-0001.pgp>
-------------- next part --------------
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l at Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l


from_name: Anthere

subject: [Wikipedia-l] Papotages

body:
I learned today the death of a previous wikipedian. He
was special, some of you might remember him, for he
was banned in november 2003, and gave a lot of work to
Tim and several to clean after him. He also is the
reason why a couple of features exist :-)

Still, I appreciated him a lot, and had discussions
with him on meta and offline, which just showed me a
gentle person with a lot of humor and intelligence. He
was a member of the raelien sect. He was essentially a
very unhappy man.

J'ai appris par Ell aujourd'hui, le d?c?s de
Papotages.

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=1r710y8t1t2ac%24.dlg%40zelohim.org&rnum=1&prev=/groups%3Fq%3Draelian%2Bpierre%2Bsidler%26hl%3Den%26lr%3D%26ie%3DUTF-8%26scoring%3Dd%26selm%3D1r710y8t1t2ac%2524.dlg%2540zelohim.org%26rnum%3D1

Personnellement, je ressens de la tristesse et du
regret ? cette nouvelle. Je ne doute malheureusement
pas d'?tre une exception parmi ceux qui l'ont connu.

C'?tait un homme tortur? et perdu, et je pense que les
actes de vandalisme dont il s'est rendu coupable au
moment de son banissement et apr?s, n'?taient que les
gestes d'un homme d?sesp?r?.

Il m'a ?crit parfois, et ces mails rec?laient une
grande gentillesse. Je me souviens d'un jour, le
dernier jour o? il a vandalis? fr. Il ?tait environ
6h30 am, et il venait de faire une tirage zantisectes.
J'ai r?vert? en silence toutes ses modifications. Peu
apr?s, je recevais un mail de sa part, s'excusant de
m'avoir impos? ce travail si t?t le matin, et me
faisant la promesse que cela serait la derni?re fois.
Et autant que je sache, ce fut en effet la derni?re
fois.

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

J'aimerais que toutes les pages de banissement le
concernant soient supprim?es. Elles n'ont plus de
raison d'?tre. S'il vous plait.

Anthere

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail


references:
<003201c46f64$a7d7b180$6401a8c0@ozymandias>
	<cdnvbr$dhh$1@sea.gmane.org> <cdocfa$eku$1@sea.gmane.org>

body:
Le Thursday 22 July 2004 14:37, Timwi a ?crit :
> Tim Starling wrote:
> > I've raised the limit site-wide to 5 MB.
>
> Why do we need a technically enforced upload limit at all? Why can't we
> leave the decision on whether to keep a large file or not to the
> respective wiki community?

It is necessary for security raisons, at least, otherwise you will see people
trying a DoS in uploading complete cdroms.

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


from_name: tic at tictric.net

body:
Am Thu, 22 Jul 2004 13:37:34 +0100 hat Timwi <timwi at gmx.net> geschrieben:

> Tim Starling wrote:
>
>> I've raised the limit site-wide to 5 MB.
>
> Why do we need a technically enforced upload limit at all? Why can't we
> leave the decision on whether to keep a large file or not to the
> respective wiki community?

Because there's a lot of idiots hanging 'round.
If they find out they'll find it fun to tease the community with
DVD-uploads or so.

Like spraying and graffiti.

--manfred

>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l


from_name: "Michaël P."

body:
Hi,

I decompressed the tgz in my installation of the previous version
of media wiki (a 1.2.6). The site still works and has the new
template.

But when I try to login, I get the following error:

  A database query syntax error has occurred. This could be
because of an illegal search query (see Searching All4dev), or it
may indicate a bug in the software. The last attempted database
query was:

     SELECT
user_name,user_password,user_newpassword,user_email,user_real_name,user_options,user_rights,user_touched
FROM user WHERE user_id=2

from within function "User::loadFromDatabase". MySQL returned
error "1054: Unknown column 'user_real_name' in 'field list'".

Obviously the database didn't update. And I don't know how to
update it manually. BTW, the help page about updating is totally
useless: http://meta.wikimedia.org/wiki/Upgrade_from_1.2_to_1.3

Thanks in advance

--
Micha?l P.
gpg:        D4C8 F73D A000 71C7 44EF  27E6 8982 4991 7126 3CE3


from_name: Anthony DiPierro

subject: [WikiEN-l] Re: some questions

body:
> Anthony, when you learn to disagree with policies through techniques
> other than edit wars, then maybe people will listen to you if you ever
> talk about being FORCED into them.

The only policy I disagreed with was the one against edit wars itself (the
same one you broke, although you also broke a number of others).  There is
and never was a policy making Raul dictator of template:feature.


body:
On Wed, 21 Jul 2004 23:28:31 -0700 (PDT), Daniel Mayer
<maveric149 at yahoo.com> wrote:
> Could the notice be put back so that most cached pages will have it by the time
> we get Slashdotted? Or was there a decision made somewhere that it should be
> taken down?

The notice was only supposed to be up whilst we were on Slashdot.
Currently we are not there, so the notice was taken down following
some complaints that it had been up for too long. Anthere and I
discussed this and decided it should be removed until Jimbo replies to
the Slashdot interview.

As it was only supposed to be a temporary measure, there is no reason
for it currently to be up. However, perhaps we should consider whether
it needs to be a more permanent measure. If the notice is bringing in
significantly more donations than we normally get, should it be there
permanently, and just made more prominent during the fundraising
drives?

Angela.


from_name: Laurent Pinchart

subject: [Wikitech-l] wakkawiki to mediawiki conversion script

body:
Hi everybody,

I've written a small python script to convert a wakkawiki database to
mediawiki. The code is far from being perfect (some features are missing,
history is not handled for instance) but it can be quite useful.

I don't plan to maintain the script (I converted my wiki and I'm happy with
it), but if someone is willing to store it somewhere (CVS ?), feel free to
do so. The code is in the public domain.

Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wakka2media.py
Type: application/x-python
Size: 8234 bytes
Desc: not available
URL: <http://lists.wikimedia.org/pipermail/wikitech-l/attachments/20040722/33e0e816/attachment.bin>


from_name: Mark Pellegrini

subject: [Wikitech-l] File formats

body:
Ok, so Jamesday proposes that we use any open or common file format. Should
I
write this into the Wikipedia:Sound policy, or is this debate going to go on
forever?
(I'd prefer it be settled before I write the policy). Jimbo - is James's
idea OK by you?

--Mark


from_name: blankfaze

subject: [WikiEN-l] Disruptive users

body:
True that, brother!  Speak the truth!
I think that by and large, as Wikipedia grows, our mechanisms for
dealing with "problem users" becomes less and less effective.  If we
don't (a) develop better, clearer policies prohibiting a wider array
of disruptions, and (b) develop methods to better and more expediently
deal with users causing disruptions...
... then we will be known as unreliable, and disorganised, and
half-rate.  The glorious project that is Wikipedia will fail (IMO).


from_name: Gutza

references:
<1090466195.d66a863cuser_Jamesday@myrealbox.com>	<40FF714E.5060609@moongate.ro>
	<cdod61$gsr$1@sea.gmane.org>

body:
That's true, but it can happily replace GIF's, it's actually smaller if
compared on par (8-bit images).

Gutza

Timwi wrote:

> Gutza wrote:
>
>> About still formats, why not use PNG? It does hold some restrictions,
>> depending on your building method
>> (http://www.libpng.org/pub/png/pngfaq.html#patents), but it should be
>> pretty much safe if we can arrange automatically converting whatever
>> format the user uploads to the "proper" (i.e. free) PNG format.
>
>
> PNG is unsuitable for continuous-tone graphics.
>
> By "unsuitable" I mean its compression isn't much better than BMP.
>
> Timwi
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l at wikimedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikitech-l
>


subject: [Wikitech-l] __ADDSEC__ keyword - A new (unfinished) feature

body:
?var Arnfj?r? Bjarmason wrote:
> diff -ru phase3_2/includes/CVS/Entries mediawiki/phase3/includes/CVS/Entries
> --- phase3_2/includes/CVS/Entries	2004-07-22 23:48:04.974484648 +0000
> +++ mediawiki/phase3/includes/CVS/Entries	2004-07-22 22:53:51.957541168 +0000
> @@ -58,11 +58,13 @@
>  /LinksUpdate.php/1.23/Thu Jul 22 22:53:51 2004//
>  /LoadBalancer.php/1.8/Thu Jul 22 22:53:51 2004//
>  /LogPage.php/1.12/Thu Jul 22 22:53:51 2004//
> +/MagicWord.php/1.20/Thu Jul 22 22:53:51 2004//

Quick note: it's best if you can make patches with 'cvs diff -u' rather
than a recursive diff of two separate checked out source trees. This
keeps CVS's bookkeeping files out of the diff and makes things a little
easier to manage.

-- 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/20040722/17be8cab/attachment.pgp>