Hi!
this may sound as a heresy, but for some jobs, that are short in time-
span, but need lots of CPU capacity we could try using Amazon's EC2
or any other grid computing service (maybe some university wants to
donate cluster time?).
That would be much cheaper than allocating high-performance-high-
bucks hardware to projects like this.
Really, we have a capable cluster that has extra-CPU capacity for
distributed tasks, but anything what needs lots-of-memory in single
location simply doesn't scale.
Most of our tasks are scaled out, where lots of smaller machines can
do lots of big work, so this wikistats job is the only one which
cannot be distributed this way.
Eventually we may run Hadoop,Gearman or similar framework for
statistics job distribution, but really, first of all the actual
tasks have to be minimized to smaller segments, for map/reduce
operation, if needed.
I don't see many problems (except setting the whole grid up)
allocating job execution resources during off peak, on 10, 20 or 100
nodes, as long as it doesn't have exceptional resource needs on a
single node. It would be very nice practice for many other future
jobs too.
BR,
--
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
Hi,
I want to get some feedback on a possible Summer of Code project proposal.
For last year's GSoC I created an HTML diffing library for Daisy CMS. The
algorithm has proven to work well and I'm thinking of porting it to
mediawiki.
What the algorithm does is take the source of 2 pages and merge them to
visualize the diff. The code I have already does something like this:
http://users.pandora.be/guyvdb/wikipediadiff.jpg
Is this a feasible project for wikimedia? I'm personally not very impressed
with the current "diff pages". I think a visual diff would bring that part
of mediawiki up to par with the rest of the software.
Thanks
Guy
For each new MediaWiki version, there is casual shifting back and
forth of what the translations of the names for the pages like the
community portal page, the disclaimers page, the current events page,
etc. are.
Each upgrade we have to repair our wikis to connect the previous page
name back up to its latest and greatest translation.
Some lucky people might be able to create global accounts at the moment,
but please note the following caveats:
1. Local access control on account creation is largely broken. The new
user log, IP blocks on account creation, and AntiSpoof conflict checking
are broken. Only private and fishbowl wikis are still protected.
2. Email address changes are local and don't propagate properly to the
other wikis.
3. There's no cookie sharing so you have to log in to each wiki separately.
4. There's no shared preferences except password
5. You can't rename a global account.
I intend on fixing items 1 to 3, in that order. I won't make any
guarantees for 4 or 5, maybe someone else is interested in them.
-- Tim Starling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
In the past few days I've been making good progress on the
ExtensionManager extension, and am at the stage where information
regarding extensions needs to be stored and polled. In the long term I
hope for these files to become widespread (perhaps in nearly all
extensions), therefore I'd like to open a discussion about the format --
once implemented it will be difficult to remove features from it, and
backwards compatibility would have to be retained indefinitely so a good
starting point would be essential.
My idea is to use an XML file for each extension, this would be fairly
easy to parse (XML support is a requirement for installing MediaWiki)
and is easy to write. My suggestion as an example format is (using
CategoryStepper as the example) is:
<extension>
<name>CategoryStepper</name>
<version>1.5</version>
<description>categorystepper-desc</description>
<mediawiki>1.11.0</mediawiki>
</extension>
While this original version is quite concise it would be easy to expand
upon if any further features were needed (for example, there is a
possibility of compatibility verification by checking class names
etc.). The extensions i18n file will also be loaded within the special
page's scope so the <description> tag correlates to a message name
allowing for internationalization. The <mediawiki> tag correlates to
the minimum MediaWiki version required, the rest are probably self
explanatory.
Any input on this matter is greatly appreciated.
Thank you,
MinuteElectron.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkfi1VwACgkQkJvUlhoE3wSDxACcDT39xPH7RK4A3gjcg15qmcKz
/RMAn0E/StcNnTVGQ89D8qX+Aw4VHY3s
=t4Yc
-----END PGP SIGNATURE-----
On Tue, Mar 25, 2008 at 9:57 AM, <siebrand(a)svn.wikimedia.org> wrote:
> * Prettification of quotes (by Jon Harald S?\195?\184by)
> -'tog-showjumplinks' => 'Enable "jump to" accessibility links',
> +'tog-showjumplinks' => 'Enable "jump to" accessibility links',
> [etc.]
Do we want this? I've always been of the mind that straight quotes
are the more normal thing on the Web, and there's no point in trying
to use curly quotes. Curly quotes look a bit odd on the Web, and
they're also hard to type and copy, which makes it annoying for anyone
editing messages (either developers or local sysops).
simetrical(a)svn.wikimedia.org schreef:
> Revision: 32179
> Author: simetrical
> Date: 2008-03-19 15:53:48 +0000 (Wed, 19 Mar 2008)
>
> Log Message:
> -----------
> Fix an error for categories named literally "Project:" or some similarly weird thing. I thought that's not a legal title, but I'm told otherwise. Is there a better way to do this than manually prefixing "Category:"? The second parameter to newFromText is ignored if there are any prefixes, according to the docs.
You could try Title::newFromText(":$foo", NS_CATEGORY); , which uses the
category namespace as the default mainspace, which is then forced by the
leading colon. I haven't tested this and I'm not 100% sure this works,
but you could try (it'd still be hackish, but it'd be cleaner than the
alternative).
Roan Kattouw (Catrope)
Yesterday, Tim Johansson (I'll call him Joti from now on, we have too
many Tims already) asked me to mentor him for this year's Google Summer
of Code. I accepted. The project he proposed was fixing bug 167 [1]
(separating category and interlanguage links from the article text in
the interface). I've read through the comments, and the issue looks
controversial. Several approaches have been suggested in the past and
there has been debate as to which one is best. Of course, I'd like to
hear from Joti what his plans are so we can discuss them here, but I'd
also like to hear opinions as to whether we should actually implement
bug 167 in the first place.
Roan Kattouw (Catrope)
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=167
On Mon, Mar 24, 2008 at 1:17 PM, <vasilievvv(a)svn.wikimedia.org> wrote:
> /**
> - * Experimental feature still under debugging.
> + * If enabled, MediaWiki checks redirects in Image: namespace.
> */
> -$wgFileRedirects = false;
> +$wgFileRedirects = true;
If this is no longer experimental, the config option should be removed
entirely, not just enabled by default.
