On Sunday 06 April 2003 05:00 am, Daniel Ehrenberg wrote:
> aparently, the wikipedia server is down. This hasn't been reported on the
> list, although this might have been because the email server is down too.
You might be surprised to know that the Wikipedia encyclopedia and the
Wikipedia mail server are both on the same box.
Could all the mailing lists work just fine on a separate cheapo AMD K6-II 500
MHZ Linux box with two 4 gig hard drives, 256MB of SDRAM and a couple network
cards? If so, I hereby donate such a dinosaur to serve as a mail server (of
course I'll have to test these components to see if they still work so the
specs may change - somebody else will have to configure the mail server part
though).
Not being able to talk to each other as a group during a crash like this isn't
exactly an optimal way to run a project the size of Wiki(p/m)edia.
-- Daniel Mayer (aka mav)
WikiKarma
The usual at [[March 29]]
It's taking upwards of three minutes just to get an Edit command to bring up an Edit screen.
Zoe
---------------------------------
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
The server was down for almost a full day, apparently thanks to a crash
which involved a slight bit of filesystem corruption which it couldn't
_quite_ recover from on bootup without a human coming in and saying
"yes, repair that sector".
I love computers. :)
Huge thanks to Jason Richey, who drove in to the hosting center to beat
up on the server in person tonight.
The server is back up; I've locked the wiki while double-checking the
database tables for corruption.
Messages to the mailing lists sent in the last day should come through,
but some may take a while to get resent from intermediate mail servers.
-- brion vibber (brion @ pobox.com)
"
Subject: Re: [Wikipedia-l] The "wikidown" address
Message-ID: <20030405072235.GA16635(a)piclab.com>
References: <20030405001619.GA13657(a)piclab.com> <8jGa0Y6SpVB@erik_moeller>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8jGa0Y6SpVB@erik_moeller>
User-Agent: Mutt/1.4i
X-URL: http://www.piclab.com/lee/
> (Erik Moeller <erik_moeller(a)gmx.de>):
> > The "wikidown" address just got spammed. Since there's no way
> > to get off of spammers' lists once on, that pretty much demands
> > that we change it. Further, whatever means we are using to
> > announce that address to human beings should probably be fixed
> > to make it less friendly to address-sucking bots.
>
> What about spamassassin? It's a pretty decent filter that should catch
> most of the spam. Getting and staying off spammers' lists seems like a
> futile exercise, and many people have now memorized the wikidown address.
I run SpamAssassin at Piclab; it's great--it reduces my mail from
about 200-300 a day down to 20-30. But the "wikidown" address is
attached to my pager, so even one a day is a nuisance.
--
Lee Daniel Crocker <lee(a)piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC
Since this would be a system-wide change, not English-only, we should
discuss it over here, too.
----- Forwarded message from "Poor, Edmund W" <Edmund.W.Poor(a)abc.com> -----
From: "Poor, Edmund W" <Edmund.W.Poor(a)abc.com>
Date: Thu, 3 Apr 2003 15:59:46 -0500
To: <wikien-l(a)wikipedia.org>
Subject: [WikiEN-l] How to ban a logged-in user (was: Wikipedia privacy)
Well, here's an idea. Give sysops emergency power to ban a logged-in user (by name), while simultaneously blindly banning their IP address -- temporarily. And they'd be honor bound to report the ban to the list, just as when a sysop protects a page to stop an edit war.
For example, user:Skeezix messes up a lot of pages, so sysop BigCheese spends countless hours cleaning up after him and finally says it's not worth it. After some discussion on the mailing list -- or in a really urgent case, unilaterally -- the sysop presses the magic "Ban this logged-in user" button.
Whereupon two things happen:
1. The user's account is blocked.
2. The user's IP address is blocked.
And one thing doesn't happen:
3. No user, not even a sysop, can see the blocked IP.
So if Skeezix tries to log in as user:Spreitel -- he can't because his IP is blocked.
Advantages:
* Stops the vandal cold.
* Avoids revealing IP addresses.
Disadvantages:
* Like all banning mechanisms, it could be abused.
* If the IP is shared by "innocent" parties, they also get blocked.
Ed Poor
_______________________________________________
WikiEN-l mailing list
WikiEN-l(a)wikipedia.org
http://www.wikipedia.org/mailman/listinfo/wikien-l
----- End forwarded message -----
http://www.federalreserve.gov/BoardDocs/speeches/2003/20030404/default.htm
>For example, though the set up cost of creating an on-line
>encyclopedia may be enormous, the cost of reproduction and
>distribution may be near zero if the means of distribution is the
>Internet. The emergence of an electronic platform for the transmission
>of ideas at negligible marginal cost may therefore be an important
>factor explaining the recent increased conceptualization of the
>GDP. The demand for conceptual products is clearly impeded to a much
>smaller degree by rising marginal cost than is the demand for physical
>products.
The cost isn't *that* enormous, of course, when a free license
empowers volunteers.
The English-language Wikipedia will be in read-only mode for maintenance
tonight/in the morning starting around 9pm PST (midnight EST; 5am GMT; 6am
most of Europe; the rest of you are on your own).
I'll be making some slight alterations to the database structure and
installing an updated version of the software to better support
client-side web caching for more browsers (so your browser will reload
pages only when they've actually changed instead of every time you visit
them). This will also enable a future update to do server-side caching
which should reduce server load significantly.
IE users, this should fix the cache bug where red links remain even after
a page has been created; the page should automatically reload with the
correct link status.
(This update has been running for about a week on meta.wikipedia.org and
test.wikipedia.org with no complaints so far.)
This will require taking the wiki "briefly" into read-only mode while
alterations are made. I don't know exactly how long it will take, but
don't be surprised if it takes about two hours. These things always take
longer than hoped. :)
The other languages will also be done around this time, but should go much
faster; there will be brief read-only outages, one at a time.
-- brion vibber (brion @ pobox.com)
> >(*) Move page only
> >( ) Make the page a redirect, and update all links so that they point to
> > the new article
> >( ) Move page and update links
>
>Q1: What's the difference between the last two options?
I thought option 2 might be controversial, but I guess if no-one understands
it that would explain why no-one has commented on it yet. Option 2 simply
changes the first page to a redirect as if someone had edited it normally.
It does not move the edit history to the new location. This would
effectively allow someone to move a page to an occupied location, without
deleting it first to make way. I'm not sure if that's a good idea or not.
>Q2: I don't really trust this idea yet and would hesitate to use it --
> although I have no objection to other editors' having it available.
> But what I'd really like is an option that changes only redirects,
> to automatically avoid double redirects. Can we add that?
> Perhaps it should even be the default?
Okay, that can be done. Let me get this straight, is this what you want:
* Double redirect exists from [[redir1]] to [[redir2]] to [[content]]
* User navigates to [[redir2]] and clicks "move/redirect page" (probably a
better name for Special:Movepage with new functionality)
* User selects the option "No move, update redirects only"
* Software chages "#REDIRECT [[redir2]]" in [[redir1]] to "#REDIRECT
[[content]]"
Is that about right? Here's another scenario:
* [[redir1]] redirects to [[old content]]. User wants to change the title of
[[old content]] to [[new content]].
* User navigates to [[old content]], clicks "move/redirect page", and
selects "Move, update redirects only".
* Software moves the page, and changes [[redir1] to "#REDIRECT [[new
content]]"
For a UI, something like:
(*) Move
( ) Change to redirect
[*] Update redirects to here
[ ] Update links from article namespace
[ ] Update links from other namespaces
Where ( ) indicates a radio button or option group or whatever you want to
call it, and [ ] indicates a checkbox.
-- Tim Starling
_________________________________________________________________
Hotmail now available on Australian mobile phones. Go to
http://ninemsn.com.au/mobilecentral/hotmail_mobile.asp
After a discussion on wikitech-l titled "bot approval request", we decided
that perhaps it would be better if my bot were implemented on the server
side, so that everyone could use it, and so that it would be relatively
efficient. I offered to do the coding, on the condition that someone will
block me if I try to make any ordinary edits -- I don't want Wikipedia
totally taking over my life :)
Anyway, here's my proposal. I originally posted it on wikitech-l, but it
drew no responses. What I'm suggesting is a significant extension to
Special:Movepage capabilities.
------------------------------------------------
What we want to be able to do is:
1) Change a set of links pointing to a redirect, so that they're pointing to
the real article
2) Change a set of links pointing to an incorrectly named image, to a new,
correctly named image.
The second one was suggested by Tarquin on [[User talk:Timbot]]. Now the
problem with this feature is that it has the potential to create excessive
server load, especially if an edit war breaks out utilising it. My scheme
below is intended to do the following things:
* Make it appear weighty and time-consuming, so that users won't do it
frivolously.
* Make the smallest impact on the server possible while not wasting people's
time.
* Make edit wars utilising the feature take up a minimum of server load, and
to favour a conservative (changeless) outcome.
As a tentative short name, I suggest the "backlink redirect". It's a
mouthful, it doesn't make much sense, but it's better than anything else
I've come up with.
Here's my current vision for how it will operate:
On Special:Movepage, you now get an OPTION group looking like this:
(*) Move page only
( ) Make the page a redirect, and update all links so that they point to the
new article
( ) Move page and update links
Any logged in user has access to these options. If the user selects the
second or third option, a new thread is created on the server, set to low
priority -- low enough that it might take an hour or more during peak times
to fix a large set of articles. This new thread does the following:
* Updates Wikipedia:BacklinkRedirects (or related DB table) to indicate that
a backlink redirect has started. This appears on RC.
* Starts updating the links, one at a time. Changes do not appear on RC.
* After it finishes updating each article, it checks to see if someone has
clicked on the "cancel" link in Wikipedia:BacklinkRedirects. If so, it
reverts its changes and stops, indicating this on RC and
Wikipedia:BacklinkRedirects.
* Once it has finished, it updates the table related to
Wikipedia:BacklinkRedirects to indicate that the job is now over. This does
not appear on RC.
The job stays there on the lower half of the page for all time, with some
method of accessing multiple pages of them. Anyone can revert such completed
jobs. Reversions of complete jobs are handled at the usual thread priority
(arguable, I could be wrong). Articles which have changed since the initial
update are, of course, not reverted.
As you can see, with this scheme, even an edit war over a huge set of links
will create little server load in peak times, as long as both sides of the
fray watch Wikipedia:BacklinkRedirects vigilantly.
-- Tim Starling.
_________________________________________________________________
MSN Instant Messenger now available on Australian mobile phones. Go to
http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp