>Very soon now, the server will be owned by the nonprofit
foundation.
Oh, really. Do you have more information regarding this? I'd
love to mention about this in wikipedia article.
On Mit, 2003-01-29 at 22:24, Michael Hardy wrote:
> > yes, we need a better way to handle edit conflicts; but in any case,
> > your work should not be destroyed! Unless something went very wrong,
> > you should be given two edit windows, one with the new version saved
> > by someone else and one with your version, and a list of changes.
>
>
> This has not happened. I was using a version of Netscape
> that may not be up-to-date; I'm not sure what would happen on
> Mozilla or Internet Explorer.
Please let me know if you can reproduce this problem, and if so, under
which conditions it appears.
> > 2) Show a warning if someone has started to edit the text < x minutes
> > before you have
> Or maybe a warning if they start to edit _while_ you are
> editing,
We can only show the warning when the edit page is loaded, i.e. to the
person editing after another person has started doing so. We need a time
limit because otherwise people could get the warning indefinitely if
someone opens an edit window and doesn't save.
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
>It seems it's usually Brion who commits stuff here, but it's
>less formal than with Linux kernel.
So, it is a kind of arbitrary.
>And it's Jimbo who owns servers.
What do you mean? I thought Bomis owns the server. Am I
right?
>Anyway, this was rather uncontroversial change.
I don't remember saying it is controversial. I am sorry for
giving wrong impression. I was just wondering about the
decision process. I don't mean to object to this change at
all. (though I advocate the system should be more democratic)
Just a note; of our current slowdowns, many are coming from locks on the
'old' table (which is still MyISAM, not the new table type). I'm going to
try tweaking the sort buffer a bit, as I notice a lot of the stuck threads
are in "sorting" state.
We may want to look at queries using the old table (reads: history list,
diffs; sometimes show old version. writes: inserts on page edit; updates
on rename; deletes on delete. There _oughtn't_ to be too much contention
on this table.) and generally fix stuff up.
-- brion vibber (brion @ pobox.com)
>On Wed, Jan 29, 2003 at 01:51:48AM +0100, Pieter Suurmond
wrote:
>> Takuya Murata wrote:
>> > The problem is set up. Surely the current dependency
hell
>> > makes hard to host mimi-wikipedia, particularly on
windows-
>> > based servers.
>
>No, you got it all wrong.
>It's not "dependency hell", it's "server-side programming".
Oh, how can I say. First, please recognize the context. If
we distribute wikipedia server to hunders of mimi-server, it
is necessary to make easy to set up. But if we don't, the
dependency really doesn't matter the
>We're supposed to use whatever we find convenient on server-
side.
>That's the paradigm on this side of network connection.
Gentelly notice the debate should be based on the reasoning
not simple assumptions.
>These dependencies aren't really that weird - Apache, PHP
and MySQL
I don't think these dependencies are weired neither.
>As for windows servers, it doesn't really matter.
>They are rather small minority, and have so many problems
>that supporting them is not really worth effort.
>Just get some Unix.
Again, if you distribute, the number of windows servers does
matter. But again the context depends.
Our search engine desperately needs retooling. If there's no objection
from those in the know, I'd like to migrate us to MySQL 4. The fulltext
search in 4 has boolean capabilities built right in, meaning we could
remove our hackish and buggy parser, and wouldn't need to stack so many
MATCHes together in a query when some poor sap types in "chemical
composition of the earth's atmosphere oxygen nitrogen" or something.
(Our search queries are also frequently *dog slow*. This is exacerbated
because, being a myisam table, it locks when someone tries to write it
and another read is pending. I don't _think_ this lock virulently
spreads to other tables joined with it, but it's annoying anyway.)
Other things to think about:
* Stopwords. Can we just get rid of the damn stopwords and search
anything?
* "Title results" vs "Text results" - this two-prong approach is, I
think, rather confusing. We could have a single search index field with
the title text weighted more heavily (by repetition?), and just give a
single set of results.
* Text extracts: these show the raw wikicode, and often include language
links, HTML code, etc. Yuck! If we can strip these, that might be good.
* Character entities: should be folded to their raw equivalents in the
search index, so searching a page containing "Schrödinger" and one
containing "Schrödinger" gives identical results.
* 'Power search' is perhaps a little confusing, and there's currently no
way to get to it short of doing two searches.
* 'Search' and 'go' buttons are not clearly demarcated; several people
have noted confusion. Better labelling or better arrangement is needed.
* Redirects. We generally want to filter out redirects that seem
duplicative of other things already listed, but *must* show them for
alternate names. Clearer labeling of redirects would help as well.
-- brion vibber (brion @ pobox.com)
>Why in the world are we now giving anon users the option to
create user pages?
Also, I was wondering where such a decision was made. The
main wikipedia mailing-list? The decision process should be
more clear and more democratic.
Best wishes,
Takuya Murata
Why in the world are we now giving anon users the option to create user pages?
Talk pages are a good idea but please don't display an edit link to "View
user page" on anon talk pages. We don't want to give them too much since that
will only result in fewer of them actually signing up for and using a user
account (which is still something we want to encourage, no?).
--Daniel Mayer (aka mav)
Hello, everyone
>Rendering a Wikipedia article requires, for example, to
look up all the
>links contained in it and determine if the pages exist or
not.
What else do we need to render wiki-marked up text? Aside
from images, I don't see any other parts that require access
to the main index.
>Actually, we had a *decrease* in traffic in the last month
due to the
>Google hiccups.
I know this.
We should be able to cope with much higher traffic if we
>optimize our queries. Note that pure bandwidth is not a
problem; the
>database tarball downloads are very fast. Ask Brion for the
server specs
>and be impressed.
Ok, so the problem is cpu usage or database optimization
stuff. I think you are right. If the database and queries to
it is too complex, decentralizing hardly improve the
performance.
By the way, notice I am not talking about only the
performance but also scalability and extenability. What
about such a case?
>2) You cite Google as an example of a huge centralized
database
No, I cited it as an of 'decentralized' database.
>Trust me, wiki is *very* hard to decentralize. It's a nice
idea, but it
>will take years until it happens. You need an architecture
like Freenet
>( http://freenetproject.org ), only scalable (which Freenet
is not),
>plus SQL-like query support.
While it is nice, it seemed for me only solution eventually.
I think finally see the gap of understanding. I was talking
about years-long project. I was talking about the time
wikipedia reaches the next milestone 1,000,000 (million-
pedia? haha). It seemed that eventually we have to go to the
same path that big sites like google or amazon went. As you
and I know, Google is heavily decentralized and it is one of
its strength. I bet you know about load balancers (I know
almost nothing about it thought). In my knowledge, most of
huge sites decentraize their site to mimi servers like
Google. We, of course, don't have finance to sustain such a
huge decentralized data-center. But we have decent
democratic community. The strehgth of us is that community.
As I wikipediaholic (ach!), I am so worried about the future
of wikipedia in terms of the server. We need definitely
better solution (if not necessary my decentralized server
idea). Possible solution includes the proposal Pieter's
published scripts or better web-site for wikipedia
developers. (It seemed quite a few people who are actually
coding for wikipedia, compared with the scale of wikipedians
writing articles)
>wiki is *very* hard to decentralize
I knew this. But can we figure out about how in here? I am
not saying you do what I told. I can cooporate of course,
tons of skilled programmers can do too I guess.
If you think this debate is totally wasting time (I mean if
I, who knows little, am annoying this mailing list), let me
know then I quit but if not, please give me a comment.
Okay, how about this? It seems to me that one of core
problems is rendering requires queries about whether the
page exists or not. I remember the post saying the rendering
of a page containg many internal links is one of bottleneck
(I suppose it is still true).
First, each mimi-wikipedia has a database about if the page
exists or not and subscribes the list of newly-made pages.
Also, when it is launched, it downloads the complete list of
new pages. Because now that each mimi knows which page
exists or not regardless its mimi-database, it is possible
to render the page without querying the main database.
For disclamiler, probably I am wrong. But if you can, can
you tell me why and how so?
Anyway, I understand wikipedia still can be optimized much
(that I didn't know in the first time I posted my proposal)
Sure, if we can optimize the database and it gains the huge
increase in performance hopefully, we should head for there
of course. The priority should be optimization of the
database. I agree.
Anyhow, I approciate your detailed explanation about the
problem we face now to me who knows really little.