Hi,
I'd like to request the immediate set-up for the following wikis.
These wikis have been waiting for quite a while and should be created
as soon as possible!!
1. Banyumasan (8)
2. Nedersaksisch/Dutch Low Saxon (21 support; 3 oppose [thereof 2
anonymous votes])
3. Ripuarian (18 support [thereof 2 anonymous votes]; 2 oppose)
4. Samogitian (Žemaitėška) (11)
5. Vlax Romany (11 support, 1 oppose [anonymous])
More info on: http://meta.wikimedia.org/wiki/Approved_requests_for_new_languages
Kind regards,
Servien Ilaino; and the
Meta-Wiki community
I discussed some ideas a few days ago on #wikimedia-tech, here's a
summary email about that.
overall goals:
- preserve all wikipedia functionality
- make it more resistant to scaling forces
- highly modular - reduce interdependence
- identify core "must have" functionality
- push everything else out to the edge as far as possible
- cache as much as possible at every level - design caching into the
system
Five logical components I'm focusing on:
- the article (all articles = the content)
- a content cache
- authentication server(s)
- UI server(s)
- squid cache(s)
As I understand the architecture today, several of these functions
are currently being performed monolithically by the appservers... so
in part I'm proposing a refactoring where the core functions
(article, content cache, authentication) are protected from traffic
by a ring of "defenses" in the UI servers and squid caches. Here's a
breakdown of each layer:
ARTICLE
- for storing the content
The unit of content is a 3-tuple: {wikitext, red coloured links,
templates}
- each time I am edited:
--- change my content
--- if I'm a new/moved article, change colour of links in articles
that reference me
--- if I'm a template, change each article that uses me
- goal:
--- when I'm edited, propagate those changes as *efficiently* as
possible to my fellow articles
--- insist that when I'm changed, directly or indirectly, I am only
read *once* by the Content cache
--- insist that I'm only changed by the authentication server
CONTENT CACHE
- for caching articles for browsing
- goal:
--- I only hit an article *once* for each change to that article
--- no one else ever *reads* from the articles but me
AUTHENTICATION SERVER
- for authenticating users for editing
- goal:
--- I'm only involved when you have to be *certain* of a user's ID
--- that is, first log-in, and when they submit an edit
--- no one else ever *writes* to the articles but me (once I've ID'd
the user)
UI SERVER
- for serving up HTML pages
- goal:
--- for browsing, I read from content cache, add user dressing, and
serve
--- for submitting edits, I send them to authentication server
tricks:
- could get into tricks with javascript, IFRAMEs, whatever to push
work farther to the edge
- could create a distributed UI server system that can be replicated
and run by universities, etc.
SQUID CACHE
- for especially non-logged in users
- goal:
--- remove browsing load from the UI server
--
http://simonwoodside.com
Hello
I noted since a couple of days a slow down when I try to submit a
contribution. Is there anything I could do like enhance the cache of
my browser?
Uwe Brauer
"Jamie Bliss" <astronouth7303(a)gmail.com> wrote
in message news:dm5mb8$8ls$1@sea.gmane.org...
> Phil Boswell wrote:
>> [note cross-posting and prune as appropriate]
>> How difficult would it be to add <<title>> attributes to the Category
>> links which appear at the bottom of articles?
>> I was thinking it might be a good idea to have some way to display the
>> "sort key" without having to delve into edit mode, so I wondered if this
>> could be displayed as a "tool-tip" when hovering over the link, in the
>> same way as the destination article is shown for a regular wikilink. Is
>> this an idea which might be helpful, or am I getting punch-drunk after a
>> difficult day?
> Shouldn't it be the other way? Display the sort key in the page itself and
> put the real title in the title="" attribute (no humor intended).
No, because you want the set of categories to which the article belongs to
be instantly visible. You would also want it readily available for printing.
The "sort key" is a secondary attribute which can safely be left hidden
unless the viewer wants to see it, and is likely to be less relavant to a
printed version.
--
Phil
[[en:User:Phil Boswell]]
Hi there, I've just joined the list. I've been contributing to the
wiki for a while, but I've got some technical interest now. To start
off with, here is a list of "conjectures" that I think are
interesting about wikipedia. I'm crossposting from my blog ( http://
simonwoodside.com/weblog/2005/11/20 ).
Conjecture 1. That the distance between any two wikipedia pages,
randomly chosen, as measured by wikilinks, is on average 6.
Conjecture 2. That wikipedia is sufficiently formal and complete that
you could build a useful general purpose AI knowledge base using it.
Conjecture 3. That wikipedia has low information entropy.
Conjecture 4. That the development of a wikipedia article over time
occurs in a manner consistent to the biological evolution of a species.
Conjecture 5. That the relationship between the amount of material in
wikipedia and the number of article views is exponential.
Conjecture 6. That wikipedia is, on average, factually accurate.
The one that I'm most interested in today, actually is #5 (known as
Reed's law) ... because today I went to do some editing and found
that the system was very slow... I'm actually a little worried that
wikipedia is going to be overwhelmed by it's own popularity. I saw
something like this happen before, when I joined a MUD called
MicroMUSE back in er... 1993??? Wired issue #3 wrote about it and
then they were inundated with users... everything was really slow...
well back then I didn't have the technical chops to do something
about but now I do. I have some ideas about architectural design of
WP's servers in mind that I discussed with some people on #wikimedia-
tech today... I'll probably write them up in a few days.
Anyway, the motivational reason is that IF conjecture #5 is TRUE,
then there's probably some severe architectural implications for WP's
technical design.
--simon
(founder of semacode, contributor to mozilla, etc.)
--
http://simonwoodside.com
Would it be especially complicated to add the namespace=? parameter to the
"What links here?" mechanism?
I would be quite happy to add it to the URL manually at first, but this
would be most useful ploughing through huge lists of links trying to make
out whether something is actually being linked to meaningfully.
--
Phil
[[en:User:Phil Boswell]]
Hello all,
I was reading the Wikibooks:Database_download page and there is a section titled
"Static HTML tree dumps for mirroring or CD distribution". This section states
that if anyone would "like to help set up an automatic dump-to-static function,
please drop us a note on the developers' mailing list".
Is there a HTML tree dump project in the works that I could contribute to?
Many thanks,
John Haselden
I just saw the recent EasyTimeline upgrade, patched for unicode compliance 4 days ago.
Unfortunately it breaks things seriously.
Could this patch be reverted until I submit a better solution hopefully soon?
With the new patch all texts with embedded links will be garbled. This is why:
EasyTimeline supports embedded links, Ploticus does not,
so EasyTimeline divides and draw texts in segments, straight text in black,
then linked text in blue, more text in black, carefully positioning each segment,
depending on alignment, etc.
Currently Easytimeline script still assumes the standard monospaced font.
So text with embedded links will be positioned wrongly with the new variable sized font.
Now Wp authors will attempt to 'correct' the scripts to accomodate current offset errors,
only to find charts are garbled again when the proper solution arrives.
My version asks Ploticus for font metrics and then handles text positioning of each segment well, with any font.
It also allows to mix several fonts, adapts line spacing to font metrics, etc.
In fact the update for EasyTimeline is ready for months and was waiting for Ploticus patch
I submitted patch for Ploticus that allows querying of Freetype font metrics.
I just checked: this patch has been included in newest Ploticus release, thanks to Steve Grubb,
so I can resume testing soon.
I know I'm late with my solution, which I announced in Frankfurt.
My health was not 100% in previous months, in fact I'm still limited in the amount of work I can do here.
I'm recovering but my day job comes first of course.
So please bear with me for a while and leave EasyTimeline font support it was in the meantime.
Thanks, Erik Zachte
On Wed, Nov 23, 2005 at 08:28:37PM +0100, J?rgen Herz wrote:
> Brion Vibber wrote:
>
> >> That reads fine and the experience is quite fast. Thanks for the work!
> >> What I don't understand is why Ganglia only shows ~ 3.3 TB of
disk_total
> >> while there should be about 4.8 TB.
> >
> > The RAID eats up some of the raw disks' space with the redundancy.
Either that
> > or I've lost track of something. ;)
>
> Hm, shouldn't 6 of 8 disks (8 - 1 for parity - 1 spare) per RAID be
> available in a RAID 5? So each array should provide 2400 GB (2232 GiB,
> don't know if Ganglia's GB really are GB or wrongly named GiB).
Sorry, the wikitech page about amane was not up to date.
Current layout:
There are three SATA RAID controllers:
Ctl Model Ports Drives Units NotOpt RRate VRate BBU
------------------------------------------------------------------------
c0 9500S-8 8 8 1 0 4 4 OK
c1 9500S-8 8 8 1 0 4 4 OK
c2 7006-2 2 2 1 0 2 - -
c2 is used for the OS, RAID 1, 60 GB.
c0 and c1 are the big array controllers:
Unit UnitType Status %Cmpl Stripe Size(GB) Cache AVerify
IgnECC
------------------------------------------------------------------------------
u0 RAID-10 OK - 64K 1490.07 ON OFF OFF
Port Status Unit Size Blocks Serial
---------------------------------------------------------------
p0 OK u0 372.61 GB 781422768 WD-WMAMY12171
p1 OK u0 372.61 GB 781422768 WD-WMAMY12037
p2 OK u0 372.61 GB 781422768 WD-WMAMY12168
p3 OK u0 372.61 GB 781422768 WD-WMAMY12168
p4 OK u0 372.61 GB 781422768 WD-WMAMY12168
p5 OK u0 372.61 GB 781422768 WD-WMAMY12168
p6 OK u0 372.61 GB 781422768 WD-WMAMY12025
p7 OK u0 372.61 GB 781422768 WD-WMAMY12168
Name OnlineState BBUReady Status Volt Temp Hours LastCapTest
---------------------------------------------------------------------------
bbu On Yes OK OK High 0 xx-xxx-xxxx
On top of the two 1.5 TB RAID10's there's LVM, generating a striped RAID0
volume with 3TB capacity.
Bonnie reported these figures for this configuration:
--------Sequential Output--------- ---Sequential Input---
--Random---
-Per Char- ---Block--- --Rewrite-- -Per Char- ---Block---
--Seeks----
Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
/sec %CPU
amane 10000 59312 99.9 337711 84.0 101595 21.8 38235 66.8 179973 20.2
1583.2 2.6
real 10m46.529s
user 5m23.604s
sys 1m36.116s
This was the fastest available configuration with redundancy. Only RAID0 was
reading
faster. The server has 8GB memory, so 10GB test file size were chosen.
Regards,
JeLuF
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f�r GMX Partner: http://www.gmx.net/de/go/partner
geni wrote:
>On 11/15/05, David Gerard <dgerard at gmail.com> wrote:
>> Damn we need the rating feature. What's holding it up right now? List
>> please, referring to current version of code. (I know the servers are
>> creaking ...)
>Do you know if the softwear has been released yet? If not it could be
>a way to get it tested.
It's been in the MediaWiki code base for months and we've been
screaming for it to be switched on (see wikien-l in all that time).
I've directly asked on wikitech-l if there's some reason this feature
is *never* going in and if I should just stop bothering, and been told
that's not the case and that there are things that need fixing first.
But the original developer (Magnus Manske) *still* can't get any clear
list of what needs fixing for it to go in.
So. What's up with Special:Validate?
[cc to wikitech-l]
- d.