Yes, the wiki server went down this morning. Jason and Brion are
on it.
At the moment, larousse is responding to 130.94.122.197 as well as
199. Brion, I assume that was done deliberately so that you can set up
the read-only backup?
--
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
The new server is up and has all the software installed on it,
so now we need to come up with a plan for moving the systems to
the new setup.
It will /almost/ be possible to do it cleanly with DNS without
anyone noticing--just bring apache up on the new server, whose
scripts will read and write the database on the old server, and
switch "www" to point to it. During the time when user's DNS
caches are still live, some will point to the old server, but
it will be sharing the same database, so both systems can run
concurrently with no problem.
The glitch: images. Those are written to the filesystem rather
than to the database, so images uploaded on one server will
appear in the database of both, but only on one filesystem.
One way to fix this is to NFS-mount the image filesystem on
both machines, but NFS is not terribly reliable and will increase
network traffic.
Another way to do it is a more traditional switchover that will
turn off the scripts on the old server when we enable to new one,
and put up a static page that points people to the new server
under a name other than "www" while their caches are still live.
Another thing to consider is moving "test" over first, pointing
to the old database, and try the transition method on that before
we try it on "www".
Jason, regardless of which way we go, you can start by reducing
the lifetime of "test" and "www" in DNS, and make entries for
"pliny" and "larousse". We also need to change the canonical
name of ww to pliny--I can do that, but I'm not sure what else
that might effect, so I haven't done it yet.
--
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
I said:
> When I type in a search request, e.g., "Unix" or "Europe",
> Wikipedia reports "No article title matches" - even if there's
> an EXACT match that "Go" will find.
Lee Daniel Crocker <lee(a)piclab.com> replied:
> Hmm. I just got lots of article title matches on both of those.
> Are you sure you're not reporting something that happened last
> night while I was rebuilding the text indexes?
No, it's been happening for over a week.
Brion Vibber <vibber(a)aludra.usc.edu> then said:
> I've gone ahead and re-enabled the title search for now.
Hooray! Thank you very much! Title search is a really useful
feature, and I'm glad to see it back.
If you ever have to disable it again, it'd be nice if the
search results said so ("Sorry, title search has been disabled")
and at least identified any exact match. But
hopefully disabling title search won't be necessary again.
Lee Daniel Crocker <lee(a)piclab.com> said:
> What /would/ be nice though is if the "Go" button were first, and
> I'll do that if I don't hear any objections.
No objections. In fact, that's a good thing.
I know that I had a blindness to that particular button - I
always hit "search" and never even noticed "go".
That's probably because mentally I wanted to find something...
so once I saw "search", I pressed it, because that was
"obviously" what I wanted to do.
Since the subject seems to have flared up again, I'm writing up my
vision of the future of wikitext syntax. I think the desire of some
here for double-spaced lists and the clarity of the spec can be
reconciled by using a line-break syntax. I like the suggestion "\\"
(double backslash, in case your mailer screws that up).
So here's how it might work: within a line, "\\" gets replaced by a
BREAK element inline, so it can be used anywhere (inside headings,
tables, etc.). When on a line all by itself, a BREAK element is
added to the currently-open block-level element, which then remains
open. Any totally blank line closes the element (as it does now).
So,
# first
# second
will produce
1. first
1. second
just as it does now. But
# first
\\
# second
will produce
1. first
2. second
or to be precise,
<ol><li>first
<br>
</li><li>second
</li>
</ol>
Likewise,
Blah blah
Blah blah...
is rendered as
<p>Blah blah</p>
<p>Blah blah...</p>
but
Blah blah
\\
Blah blah...
becomes
<p>Blah blah
<br>
Blah blah...</p>
BTW, I did look at the links provided for other efforts at
unifying syntaxes, but they both seemed to me to be too complex
and too different from out current syntax to be practical here.
I really think I can make a syntax that is dead simple, not a
drastic change, and more powerful. I'll post the URL here when
I finish the writeup.
--
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
Please don't publicize this URL to everyone, both because it will
go away and because the old server is still sharing the database
with it and I don't want it swamped, but:
http://larousse.wikipedia.org
Is running on the new server, talking to the database on pliny.
It would be nice if a few of you went there and did some testing
to make sure I didn't screw up anything major.
This is NOT a test database--it is talking to the real live
Wikipedia database, so don't "test" any pages you don't want
changed for real.
--
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
As announced, I patched LanguageDe.php in CVS.
Now a real developer has to activate it.
Smurf
--
------------------------- Anthill inside! ---------------------------
When I type in a search request, e.g., "Unix" or "Europe",
Wikipedia reports "No article title matches" - even if there's
an EXACT match that "Go" will find.
Can "Search" do the following:
1. Report an EXACT match, if there is one, no matter what?
2. Report that title searching has been disabled (if it has),
instead of reporting that there are no matches?
I understand why it's been disabled (performance), but it
gives new users a MUCH worse impression of Wikipedia's contents
than is deserved. Currently, it looks like Wikipedia has no
content, and it CLEARLY reports that there are no title matches
even when there are. I suspect many people don't notice the
"Go" button - I didn't until someone else mentioned it
on the mailing list.
I put this in as a Bug report, but I'm not sure I made myself
clear. Sorry if I wasn't clear.
Thanks.
erik_moeller(a)gmx.de (Erik Moeller) said:
> Just because you're currently talking about the parser I thought I
> might bring up an issue which should be fixed in a next
> generation parser:
>
> * foo bar
> foo
>
> Becomes
>
> <UL><LI>foo bar
> </LI></UL>
> foo
>
> It should become
>
> <UL><LI>foo bar foo
> </LI></UL>
>
> I generally agree that wiki markup should not span linebreaks, but
> here I think it should at least span single linebreaks.
> Otherwise it gets very
> hard to format bullets with long paragraphs...
I agree. I find the current behavior rather inexplicable,
since in "normal" paragraphs, inserting a single linebreak
and continuing the text simply continues the paragraph... but
if I convert it to a list, I have to suddenly remove linebreaks.
In particular, this makes "diffs" hard to follow.
Consistency is a good thing. Basically, a single linebreak
should mean nothing UNLESS the beginning of the next line has
a special marker (e.g., *, #).
If this change were done, it might affect some text... but probably
not that much. A search could find such text and fix it.
One problem is that this would mean that you couldn't have an
embedded list in a paragraph, followed by more text without
switching to a new paragraph. I guess you could permit
embedded HTML <ol>..<li>..</ol> if you wanted to support that.
In general, it would be good to have a more formal definition of
the Wikipedia Wikitext format somewhere.