Re: [Wikitech-l] It makes more overload to delete system massages in local wiki's MediaWiki namespace pages?
Platonides platoni...@gmail.com wrote in message news:gp8rli$al...@ger.gmane.org... Don't worry about performance, delete from the wiki and use betawiki. http://en.wikipedia.org/wiki/Wikipedia:Don%27t_worry_about_performance The files get heavily cached. A page-existence check is faster than retrieving tha page, but in this case, all mediawiki messages are cached at memcached. Performance difference will be minimal. I would expect it to be slighty faster with files but the error level can make it behave the other way. Is there a noticeable performance difference between the two methods if memcached is not available? Obviously this is not applicable to WMF wikis, but I imagine the majority of wikis run without any external caching (beyond whatever is present in MW itself). - Mark Clements (HappyDog) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia is full
On Wed, Mar 11, 2009 at 5:59 PM, Tim Starling tstarl...@wikimedia.orgwrote: I would suggest either using IRC or waiting patiently. Or wikitech-l, in which case someone else will surely forward your message to IRC :). (Unfortunately, it'll also spawn 30 posts about whether or not it was appropriate to post to wikitech-l.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] It makes more overload to delete system massages in local wiki's MediaWiki namespace pages?
On Thu, Mar 12, 2009 at 7:49 AM, Mark Clements (HappyDog) gm...@kennel17.co.uk wrote: Is there a noticeable performance difference between the two methods if memcached is not available? Obviously this is not applicable to WMF wikis, but I imagine the majority of wikis run without any external caching (beyond whatever is present in MW itself). In this case, going to the database is drastically slower. On the other hand, you have to go to the database anyway, because you don't know if the message exists in the database without querying it. So there's probably no big difference in this case either. Users without a cache should consider disabling $wgUseDatabaseMessages entirely, or use some other caching method like $wgLocalMessageCache (don't know if that actually works). They should see a large speedup from this. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] research-oriented toolserver?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh Gregor: If I understand correctly, the only change being contemplated here is not replicating the databases that are entirely secret (databases of private wikis). this is correct. I might be misunderstanding, though. If only entire databases need to be hidden, why can't the toolserver just be set up not to replicate those, given that MySQL supports that? because it would require a proxy server under WMF control that filtered out the evil tables and provided a clean replicated feed to the toolserver, which is a lot more effort (and more fragile) than just moving the bad data. - river. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (HP-UX) iEYEARECAAYFAkm5FO8ACgkQIXd7fCuc5vKOhQCdGrF+u80Y4H8H/YcKwyTxce/5 iM8AnRAaS/xAuouawGht0/clWe13H8FG =hwrB -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] research-oriented toolserver?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Morten Warncke-Wang: What do you think? Seem like a useful idea if we can find sufficient resources, and put together a management plan? no, like Daniel said, this is a waste of time and effort. i originally assumed that a research toolserver would be different in some technical sense, which might make at least some sense (although i've argued against that elsewhere in this thread). however, i completely fail to understand your reasoning here. is there some backstory i'm missing? did you apply for a Toolserver account and were rejected because you aren't a Wikipedia editor? does the WM-DE have a history of doing this? (i'm certainly not aware of it, if so...) if you want to improve the account approval process at the Toolserver, doesn't it make more sense to do that, rather than creating a completely new project to fix one small issue? - river. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (HP-UX) iEYEARECAAYFAkm5FnwACgkQIXd7fCuc5vJCTQCgrdu1UILmXifN4KAfMM64FVk5 seUAoKw3jUuQW9kp/aHdSqAs3lZBX82T =PRVy -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] research-oriented toolserver?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brion Vibber: Could be done. We're also fine with new toolserver roots as long as we approve em too for now. it would have been nice if the Toolserver was aware of this ;-) - river. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (HP-UX) iEYEARECAAYFAkm5GLgACgkQIXd7fCuc5vJNTwCbBLBE5grZpHtLrKj8IiAgNTFN 8awAoKyAtofejah80yBSR4XaNSmEv3L0 =fFvc -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia is full
Or wikitech-l, in which case someone else will surely forward your message to IRC :). I think you people should follow the trend and twitter about it. someone will definitely follow and notice! -- Domas Mituzas -- http://dammit.lt/ -- [[user:midom]] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Illegal mix of collations after upgrade to 1.14
Aran wrote: I've found that by setting $wgDBmysql5 to false things seem to work ok, but is this really a good solution? I'd like everything to be running up to date, not in some backward compatibility mode... does anyone have any idea how to fix the problem properly? It's not a backwards compatibility mode. It's just a different configuration. In fact, Wikimedia servers are working with mysql 4.0! :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] research-oriented toolserver?
Anthony schrieb: On Tue, Mar 10, 2009 at 12:29 AM, Andrew Garrett and...@werdn.us wrote: On Tue, Mar 10, 2009 at 3:21 PM, K. Peachey p858sn...@yahoo.com.au wrote: Currently all data, including private data, is replicated to the toolserver. We could not do this with a third-party server. My understanding is that the the toolserver(/s) are owned by the german chapter and not by wikimedia directly so why is private data being replicated onto them? Because it was chosen as the best technical solution. Is there a specific problem with private data being on the toolserver? If so, what? You should be aware that toolserver roots are approved by the foundation before becoming roots. You answer the questions in your first paragraph with your sentence in the second. Think Cathedral vs. Bazaar. On Tue, Mar 10, 2009 at 4:27 AM, Daniel Kinzler dan...@brightbyte.dewrote: Robert Rohde schrieb: On Mon, Mar 9, 2009 at 9:29 PM, Andrew Garrett and...@werdn.us wrote: Logistically it would be nice to have a means of providing an exclusively public data replica for purposes such as research, though I can certainly see how that could get technically messy. As far as I know, there is simply no efficient way to do this currently. How much information does the live feed provide? Every revision, or just a subset of revisions? How much would it cost the WMF to provide a single near-live stream of every revision? A feed service for all revisions is available, see http://meta.wikimedia.org/wiki/Wikimedia_update_feed_service. Search engines like to use it (think: answers.com) and they are made to pay for it. Researches should generally get it for free. Just ask brion. This doesn provide notifications in the range of seconds (which might bee needed for vandal-fighting tools), but should be quite sufficient to keep a text database up to date. For real-time notifications, the only decent method is the RC feed on IRC, but that's hard to parse and messages frequently get truncated. Having better means for distributing notifications of changes is something i'm quite interested in. XMPP would be a very good choice, I think, I wrote about it a while ago here: http://brightbyte.de/page/RecentChanges_via_Jabber. I did not write about including full revision text or diffs in the notifications, but that's sure possible. It may be a bit too heavy for a general purpose feed, but it would be feasible wehen using PubSub, I think. Anyway, getting this implemented would be nice. If anyone has time and/or money he could commit towards this, that would be excellent :) -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Illegal mix of collations after upgrade to 1.14
Platonides schrieb: Aran wrote: I've found that by setting $wgDBmysql5 to false things seem to work ok, but is this really a good solution? I'd like everything to be running up to date, not in some backward compatibility mode... does anyone have any idea how to fix the problem properly? It's not a backwards compatibility mode. It's just a different configuration. In fact, Wikimedia servers are working with mysql 4.0! :) Well, it *is* called compatibility mode. I suspect because it works with old versions of mysql. In any case, the experimental modes should be fixed if broken. But they *are* experimental. So it's no surpriese if they are broken. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] It makes more overload to delete system massages in local wiki's MediaWiki namespace pages?
Aryeh Gregor schreef: On Thu, Mar 12, 2009 at 7:49 AM, Mark Clements (HappyDog) gm...@kennel17.co.uk wrote: Is there a noticeable performance difference between the two methods if memcached is not available? Obviously this is not applicable to WMF wikis, but I imagine the majority of wikis run without any external caching (beyond whatever is present in MW itself). In this case, going to the database is drastically slower. On the other hand, you have to go to the database anyway, because you don't know if the message exists in the database without querying it. So there's probably no big difference in this case either. Also note that by default, the objectcache table in the database will be used to cache messages in. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to delete Talk:Project_talk:Community Portal?
jida...@jidanni.org hett schreven: What is the best way to delete a page with a name like Talk:Project_talk:Community Portal: that even deleteBatch.php can't deal with, as you can see in https://bugzilla.wikimedia.org/show_bug.cgi?id=11487 Trying to browse it only gets as close as http://taizhongbus.jidanni.org/index.php?title=%E7%89%B9%E6%AE%8A%3ASearchsearch=%E8%A8%8E%E8%AB%96%3A%E4%B8%AD%E5%85%AC%E8%A8%8E%E8%AB%96%3ACommunity+Portalgo=%E9%80%B2%E5%85%A5uselang=en However dumpBackup.php will show its contents. Anyway, what is the best way to delete it without damaging the database? I wonder why is this title illegal at all? And how did you create it when it's illegal? Marcus Buck ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to delete Talk:Project_talk:Community Portal?
On Thu, Mar 12, 2009 at 3:58 PM, jida...@jidanni.org wrote:
What is the best way to delete a page with a name like
Talk:Project_talk:Community Portal:
that even deleteBatch.php can't deal with, as you can see in
https://bugzilla.wikimedia.org/show_bug.cgi?id=11487
maintenance/cleanupTitles.php --fix
On Thu, Mar 12, 2009 at 4:22 PM, Marcus Buck w...@marcusbuck.org wrote:
I wonder why is this title illegal at all?
The non-namespace part of the title cannot begin with a namespace
prefix. This is probably useful to avoid confusion like :Talk:Foo
being a page in the main namespace, with Talk:Talk:Foo its talk page,
as opposed to Talk:Foo, which would be the talk page of Foo. Or {{X}}
transcluding Template:X, but {{Talk:X}} not transcluding
Template:Talk:X. Or similar craziness. There might be a more
clear-cut reason for it as well.
And how did you create it when it's illegal?
Usually this happens when namespace names change, so that formerly it
didn't start with a namespace prefix but now it does. Since both
namespace names in this case are canonical and will always exist, I'm
not sure how it came to be.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] research-oriented toolserver?
On 3/12/09 7:14 AM, River Tarnell wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brion Vibber: Could be done. We're also fine with new toolserver roots as long as we approve em too for now. it would have been nice if the Toolserver was aware of this ;-) I was pretty sure this came up in an IRC chat a few months ago; my apologies if we didn't both realize it. :) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] how to delete Talk:Project_talk:Community Portal?
AG maintenance/cleanupTitles.php --fix Ahh.. thanks. Hmm, doesn't update RecentChanges... probably a feature, not a bug. OK, zapped it. And how did you create it when it's illegal? AG Usually this happens when namespace names change, so that formerly it AG didn't start with a namespace prefix but now it does. Since both AG namespace names in this case are canonical and will always exist, I'm AG not sure how it came to be. Probably in our effort to stay abreast of the ever changing zh-tw translation strings. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] [ri...@loreley.flyingparchment.org.uk: [Toolserver-announce] toolserver admins wanted]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 in case anyone here is interested... - - Forwarded message from River Tarnell ri...@loreley.flyingparchment.org.uk - Date: Thu, 12 Mar 2009 23:56:10 + From: River Tarnell ri...@loreley.flyingparchment.org.uk To: toolserver-annou...@lists.wikimedia.org Cc: toolserve...@lists.wikimedia.org Subject: [Toolserver-announce] toolserver admins wanted - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, we're now (again) looking for new admins. i originally posted this about a year ago, but we ended up not being able to add new admins then, so nothing happened. if you applied then, please feel free to re-apply. we are looking for someone with experience using the following in a production environment: + General Unix to an expert level (say, 7-10 years experience at least) + Solaris + general administration + patch management + live upgrade + ZFS + jumpstart + MySQL + Debian Linux people without this experience may be considered, if you're willing to put in the effort to get up to speed quickly. knowledge of the following would be helpful: + C and/or C++ programming language + PHP + Veritas + Sun Java System Web Server + Zeus Web Server + Apache + LDAP (Sun DSEE) some tasks the new admin might start with: + designing and implementing a monitoring system to provide current and historical statistics about the cluster, warning about problems, etc. + implementing a network install (jumpstart) framework to enable (re)installation of hosts easily, with proper post-install setup. it would be particularly nice to have another 'on-call' admin besides myself, for when there are urgent problems with the cluster and no one is around. you should either be a well-known and trusted member of the community, or else have some kind of professional background (either academic or commercial). we might require references for the latter, depending on the situation. you will be required to provide the Wikimedia office with proof of your identity. if you're interested, please mail me privately (not the list), including some information about yourself and details of your relevant background/experience, and an estimate of how much time you might be able to donate. you may include a CV if you wish. - river. - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (HP-UX) iEYEARECAAYFAkm5oRoACgkQIXd7fCuc5vK7LQCgg9KjbZ5Cajfv3S/Sert2pjIf zjIAnRe9qm31QU61G+x2cuZVwHnZ8DwZ =Qyhz - -END PGP SIGNATURE- ___ Toolserver-announce mailing list toolserver-annou...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/toolserver-announce - - End forwarded message - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (HP-UX) iEYEARECAAYFAkm5qI8ACgkQIXd7fCuc5vL1hwCfawuk/m7x5EQalpXefIWbiKdo eWIAniUcnqoy2L68v3WxLoxaktkrmL2b =el/s -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: Re: [Foundation-l] Report to the Board of Trustees: December 2008
Brion Vibber wrote: Quite the opposite -- it's extremely relevant to indicate familiarity with a similar issue in the past, which may have regressed or may have a related cause and fix. -- brion The problem is that in this case, the comment seemed to be It was fixed time ago, rather than That's a regression, we dealt with it time ago. Language is complex :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
