I've made two tweaks to the CVS commit messages that get sent to the
mediawiki-cvs list:
* Unified diff (-u) should be easier to read in most cases
* Mail headers include a charset specifier, so UTF-8 text should display
correctly in your mail reader
To support the latter, we now have a slightly customized version of the syncmail
script in our local CVSROOT, rather than using SF's global copy.
-- brion vibber (brion @ pobox.com)
Hi all,
I imported the english database dump (pages_current.xml.bz2) in
mediawiki 1.5 and it worked fine. Does the same dump works well with
mediawiki 1.4.5 as well. I am a bit worried as the database schema of
the 2 mediawikis are different.
Another small problem. If you go to the following url:
http://download.wikimedia.org/wikipedia/en/
the full wikipedia page dump(pages_full.xml.bz2) seems to have a size of
14.1 GB but when I download it its size is only 2GB. Any clue what went
wrong?
A prompt reply will be highly appreciated !
Candy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Timwi wrote:
> No, it doesn't; Wikipedia isn't "a wiki about (encyclo)pedia(s)",
> Wiktionary isn't "a wiki about dictionary", etc. It's still incorrect
> though because it's not a wiki :)
You're right! Wikipedia is an "encyclopedia run on a wiki." So
Wikistatus should be a "status run on a wiki." If you interpret wiki
liberally and say "a collaborative Web site set up to allow user
editing", WikiStatus isn't that far off the mark... but you're right,
it's not a wiki. It's... hmm... an page with user-switchable status
flags with imageboard style comment system. Now, to compress into a
catchy two word phrase...
Tels wrote:
> Heartbeat? Or, on a less serious note: CanYouHearMeNow? :)
Timwi wrote:
> In that case, call it "SiteStatus"?
Mmm... they're a bit too generic. (and CanYouHearMeNow is based off an
ad, am I not mistaken?) I like SiteStatus, but it doesn't indicate that
it is community run... I'm not good at naming either, as you can see. :o)
- --
Edward Z. Yang Personal: edwardzyang(a)thewritingpot.com
SN:Ambush Commander Website: http://www.thewritingpot.com/
GPGKey:0x869C48DA http://www.thewritingpot.com/gpgpubkey.asc
3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFDiiybqTO+fYacSNoRAh8pAJwIj2tOtrzF6wxNbRa+zJlsIEDVfgCdFaBv
Vv2dwxkgAxCQw1F92qFfI1E=
=VU9k
-----END PGP SIGNATURE-----
Anthere wrote:
> This does not show the daily work of maintenance, install and improvement
> though...
True, but if you wanna take a closer look at their daily work, visit
http://wikitech.leuksman.com/view/Server_admin_log
Jürgen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
OpenFact's Wikipedia Status ( http://tinyurl.com/48a5m ) is the original
Wikipedia Status page. However, it suffers from a huge problem: it is
prohibitively unwieldly to use. The solution? Create a more streamlined
application designed for the exact task of allowing the community to
report on contingency issues. Yup... it's called WikiStatus for lack of
a more creative name.
You can view an online version of it here: http://tinyurl.com/a62lu and
the source code is here: http://tinyurl.com/b9z8n
I'm not sure when/how OpenFacts became the de facto standard for status
reporting, but it would be cool if we could add a link to WikiStatus
from the standard error page. Of course, it's really new software (I
consider it alpha quality) and it probably needs to be audited, but when
there's a problem, there should be multiple contingency sites.
Please check it out! Thanks. :D
- --
Edward Z. Yang Personal: edwardzyang(a)thewritingpot.com
SN:Ambush Commander Website: http://www.thewritingpot.com/
GPGKey:0x869C48DA http://www.thewritingpot.com/gpgpubkey.asc
3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFDh9quqTO+fYacSNoRAmKQAJ4654F+d8NrScr40cwdek8x7Mky8wCfa3RU
beH7MlBjYFiqejEZChf8EnA=
=S57w
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eh... no one has actually commented on the program itself... :(
Dirk Riehle wrote:
> I think it would be good to make sure we don't equate the world of
> wikis with Wikipedia. [snip]
>
> I recognize that you use WikiStatus only as a shorthand for Wikipedia
> Status and spell it out most of the time, but sometimes acronyms
> take on a life of their own, say if you register a domain for it.
On second thought, the name doesn't seem that good. WikiStatus implies
that it is a wiki about status (which is incorrect). The next
interpretation is that it's the status of a wiki, Wikipedia, which is
not true either: the software should be usable for any service out there
on the web even though it was originally designed for Wikipedia.
SJ <2.718281828(a)gmail.com> wrote:
> So wikipstatus.com, with a silent p?
Well, it would be a .net, but no. :o) Any other suggestions?
Brion Vibber wrote:
> More importantly, it's on an unreliable, buggy, insecure old version
> of MediaWiki on somebody else's site which is less reliable than
> ours. That's why the links to it were removed some time ago.
Here's the old message:
Mark Ryan wrote:
> Note that I have removed the link to OpenFacts.berlios.de, which was
> getting overloaded as soon as Wikipedia went down. I have also removed
> the link to the "offsite donation page" at Angela's request. The
> French, German and Japanese messages direct those people to that
> language's IRC channel.
It's a pity, because pages like OpenFacts are useful precisely because
they're not as fast paced as IRC (IRC channel gets flooded anyway), and
have loads of useful links.
What I'd really like to do is have Wikipedia set up an official
contingency site and re-add the link to the error page. That's why I did
this. So I'm sort of waiting for your blessing. ;)
- --
Edward Z. Yang Personal: edwardzyang(a)thewritingpot.com
SN:Ambush Commander Website: http://www.thewritingpot.com/
GPGKey:0x869C48DA http://www.thewritingpot.com/gpgpubkey.asc
3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
iD8DBQFDiO04qTO+fYacSNoRAm/LAKCBBmUJCPtzIgphIM3Cee7+/6eFWACeKtQi
byb877FnjZsqn7eGy8q2L38=
=Xexu
-----END PGP SIGNATURE-----
Hello, just a shameless copy-paste from meta (http://
meta.wikimedia.org/wiki/Cluster_report%2C_September-November%2C_2005)
These months were yet again amazing in Wikimedia growth history.
Since September request rates doubled, lots of information added,
modified and expanded, more users came.
To deal with that site had to improve both software and hardware
platforms again.
Of course, more hardware was thrown at the problem.
In mid-September three new database servers (thistle,ixia,lomaria)
were added to the pool, removing ancient type of hardware from the
service.
With data growth rates 'old' 4GB-RAM boxes could not keep up with
operation, except quite limited one.
40 dual-opteron application servers have been deployed, conserving
our limited colocation space, as well as providing lots of
performance for a buck.
One batch of them (20) was deployed just this week.
They're equipped with larger drives and more memory, thus allowing to
place various unplanned services on them (9 apache servers are
storing old revisions as well), some servers participate in shared
memory pool, running memcached.
One of really efficient purchases was 12k$ worth image server
'amane', providing us with storage space and even ability to to
backup at current loads.
It is running now highly efficient and lightweight HTTP server -
lighttpd.
So far images are served, but growth of Wikimedia Commons will force
us to find a really scalable and reliable way to handle lots of media.
Additionally 10 more application servers are ordered together with a
new Squid cache server batch.
These 10 single-opteron boxes will have 4 small and fast disks and
should enable efficient caching of content.
As all this gear was bought for donated money, we really appreciate
community help here, thank you!
Yahoo supplied cluster in Seoul, Korea has finally got into action,
bringing cached content closer to Asian locations, as well as having
master databases and application cluster for Japanese, Thai, Korean
and Malaysian Wikipedias.
For internal load balancing Perlbal was replaced by LVS, and we've
got a nice flashy donated load balancing device that may be deployed
into operation soon as well.
LVS has to be handled with care and several tiny misconfiguration
incidents seriously affected site performance.
Lately the cluster has became quite big and complex and now we need
more sophisticated and extensive sanity checks and test cases.
There are lots of work in establishing more failover capabilities -
we will be having two active links to our main ISP in Florida.
Static HTML dump is (becoming) nice and usable and may help us in
case of serious crashes. It can be served from Amsterdam cluster as
well!
As for last several days we managed to bring cluster into quite
proper working shape, now it's important to fix everything and
prepare for more load and more growth and yet another expansion.
We hope that we will be able with the help of community to solve all
our performance and stability issues and avoid being Lohipedia :)
Lots of various problems were solved so far in order to achieve what
we have now, and lots of low hanging fruits have been picked.
What is dealt now with is complex and needs manpower and fresh ideas
as well.
Discussions are always welcome on #wikimedia-tech in Freenode (except
during serious downtimes :).
And, of course, Thanks Team (or rather, Family)! It is amazing to
work together!
Cheers,
Domas
The site was randomly slow for the last week or two, maybe 10% of requests
would time out. And for a couple of days, requests through the Amsterdam
squids were timing out very regularly. Both problems are fixed now. I
apologise that it took us so long to figure out -- it was a very frustrating
problem that took a while despite the best efforts of the sysadmin team. In
both cases it was subtle LVS misconfiguration, we're developing automated
tools to test for similar problems occurring in the future.
After that was fixed, I finished setting up the 20 new dual opterons, and
put them into apache service. So service times for CPU-intensive operations
should be quite good. And of course Brion put amane into service last week,
so the problem with image load times should be fixed. The Florida squids
might still be a bit slow, we have more on order.
-- Tim Starling
PHP 5.1.0 has finally come out of release-candidate status. At some point next
week we're going to try migrating; at that point we'll be able to make use of
new PHP 5 features in MediaWiki code, such as exceptions to simplify
error-handling, the improved XML reading support, etc.
This does mean that MediaWiki 1.6 will not run on PHP 4; it'll require PHP 5 or
5.1. Sorry for any inconvenience this may cause to third-party users on limited
hosts still running older versions.
-- brion vibber (brion @ pobox.com)