As wikipedia is slow at the busy time, I propose to get some new servers for our cluster.
- Some new web servers(3 or 4), P4 2,8Ghz with 2Go of RAM
- A server which could be a backup for nfs server, zwinger, with bigger disk, 80Go is very low, maybe 200 or 250Go
- Upgrading disk of zwinger to 200 or 250Go (or add a new one)
- A db server in 64 bits mode with 4Go of RAM (if we cant make working geoffrin), like this one :
With raid 10 disk system, 4 or 6 drives in raid and 1 stand-by. I prefer 15000rpm disk, but I can understand that they are more expensive
- Maybe another squid server
What do you think of that ?
Firstly, I'm disappointed Erik chose to characterise my stated
motivation as "false pretenses", as if I had some kind of bias towards
Klingon and I deliberately tried to mislead the list. I mistakenly
created Klingon, I did not try to pull a swiftie on the Wikimedia
community. I hope that Erik's choice of words was in error.
Jimbo issued one statement against Klingon and one statement in favour
of Klingon. His opinion was thus sufficiently ambiguous that my pretext
was removed. However he later clarified his position by withdrawing his
initial statement -- both on wikitech-l and on #wikipedia. I would have
been happy to re-enable the wiki as soon as he did this, however he
asked me to wait for the discussion to pan out.
The compromise agreed to by Erik and Timwi is to allow the Klingon
Wikipedia, but to avoid interlanguage links. Accordingly, I have
commented out the Klingon entry in $wgLanguageNames. This means that
markup of the form [[tlh:wIqIpe'DIya]] will create an external link
rather than an interlanguage link, just like links to meta or sep11.
Otherwise the wiki is fully functional.
-- Tim Starling
In de: we have a lot of articles on graph theory missing example images. Graphs
are also useful in other articles to visualize information. Editing images of
graphs with your favorite program and format is a consumption of time and nobody
can easily alter my images. We do have <math> and <hiero>-section. I'd like
editable graphs with <graph>...</graph>.
We could easily use the DOT-syntax and
to create PNG-images or SVG. It's damn powerful and not that complicated!
In the new default skin, the Alt-B key combination seems to bound to the
"what links here" function. Alt-B is normally the shortcut to the
bookmarks, at least in my browser (Mozilla Firefox). I find the binding to
"what links here" rather annoying, because it blocks me from a keyboard
shortcut. I doubt that I'm the only one annoyed by this.
I suggest that the Alt-B key mapping be dropped or changed to something
Greetings from Troels Arvin, Copenhagen, Denmark
Patent nonsense of course refers to the US and Japanese laws which allow software patents. Fortunately the rest of the world isn't (yet) so daft. However, before we get too caried away with banning the world's standard formats, lets consider what it involves us banning:
*JPEG (the Forgent patent, Sony paid and an unnamed comapny paid US$15 million). So, most current camera photos will be banned. I'm not yet aware of a suitable alternative, though I hope there's one. I doubt that there's one with wide enough browser support for our purpose. If you're not aware of this one, search - it'll probably be the top Google result.
*GIF of course, still royalties required in much of the world, though not the US. I assume that we'll ban something allowed in the US but encumbered elsewhere? I hope not,though - it would be foolish.
*Most video formats. JPEG, MPEG, MP4 (including DivX), Real Media, Microsofts. I'm aware of some work in this area but nothing which will meet the needs of our users for at least a year or three.
*Most fonts. Apple has patents on much of the core font hinting technology. We use fonts covered by these patents and if you've seen the alternatives, you probably won't want to switch to using them. See http://www.freetype.org/patents.html for a summary of the issues.
*Probably others - I didn't take more than a few seconds to come up with this list.
So, should we ban the most widely availabel and backwards compatible still image, audio, video and font technologies from Wikipedia?
With respect, that would be shooting ourselves in the foot.
We do need to recognise that these are the formats people have. And recognise that, however much we may like it, Windows 95 may not have support for Ogg. Libraries, schools, offices and many other places prohibit software installation without permission and we probably don't want to bar those users from our content, nor third world or poor users who may have older equipment.
We do, of course, want to encourage the use of formats which are less restricted. While doing that we should remember that it's common for patent holders to wait a decade and then spring a trap, even when they have participated in standards meetings where participants were asked to disclose their patents in advance. We do need to remember that the format we think is patent free may not be.
Rather than doing this piecemeal, lets try to find a policy we and our users can live with today, and one which encourages people to use new formats without blocking those who don't yet have those new formats. The ICANN did that yesterday. It announced the start of IPv6 support in the core DNS servers started yesterday and also said that IPv4 would be supported for about 20 years to allow a smooth transition time.
So, I propose for all encumbered formats:
*We accept and use the de facto standards, including JPEG, MP3, MPEG and Apple patented type.
*Where there is a less encumbered alternative, we encourage people to also make that available and to list the less encumbered format(s) first, to increase awareness of that format.
*Browsers send information on the formats they support. Where we have multiple formats available, we should serve the least encumbered format the client says it can support. This will involve changes to the software, which can, I hope, be done fairly slowly as we develop standards for specifying alternative forms of all multimedia works.
*Where there is a clear advantage in content or technically, we accept the encumbered format until it's clear that the vast majority (at least 99%) of users support the new format seamlesly, just as we have our target for browser support at about that level.
*Where content requires it, we support a format forever. One example is legal cases involving specific media types, where an accurate article will require the use of the exact media type used as evidence or alleged to be infringing. There's simoply no substitute for the exact file used in this sort of situation.
*When we do phase out a format, we provide a link to the old file and an archive of all such files with information about where they were used, so we don't completely lock out those who are not able to support the new format.
*When we plan to phase out a format, we give at least two yers notice and do not do so until we have alternatives available for all affected content.
*Where we are aware of external links to a specific format, we continue to make that format available for as long as the link exists.
This approach avoids failing to serve the existing clients, promotes the new formats and provides clear transition times and goals to allow resuers to adapt at a predictable pace.
I was tempted to suggest the copyleft approach: use all of the formats the US and Japanese laws encumber and not serve them in the US and Japan, to encourage people to get those nasty laws changed. I took pity on the people in those places, though.:)
Hey you out there -- have you submitted bug fix patches that haven't
been applied yet? (I'm pretty sure there are a few.) I know that's awful
If so, please repost them here so we can get these committed or
corrected and move on to the next set of fun bugs. :)
If possible, do a 'cvs diff -u' against the current main CVS branch so
it can integrate cleanly. Mail often munges plaintext patches, so please
either attach a gzipped copy or just post a URL. (If there's a relevant
bug report on SourceForge, you can upload the file there.)
-- brion vibber (brion @ pobox.com)
Maybe not the best solution, but simple and not very dirty.
Makes a merge of correct template args to recover entire wikilinks [[(...)]]
Le bon sens consiste beaucoup à connaitre la nuance des choses.
Montesquieu, "de l'esprit des lois"
Emmanuel Engelhart ICQ UIN : 53388731 TEL (+49)(0)184.108.40.206.03.31
This patch provides the possibility for adding a comment with an admin
Le coeur a ses raisons que la raison ne connaît pas.
-- Blaise Pascal
Emmanuel Engelhart ICQ UIN : 53388731 TEL (+49)(0)220.127.116.11.03.31