med a écrit 1266 commentaires

Oui, mais Wikipédia ne permet pas le fork

Qu'est-ce qui te fait croire ça au juste ? Tu peux lancer un fork dans les dix minutes. Voilà le logiciel : http://wikipedia.sourceforge.net/(...) et voilà le contenu http://download.wikimedia.org/(...) .
De plus, wikipédia n'est certainement pas plate. Dans un article plusieurs points de vue peuvent être explicités.

MediaWiki est un moteur Wiki très puissant en PHP/MySQL et très facile à installer

Il me semble que Mediawiki fonctionne aussi très bien avec PostgreSQL. Seul le script d'installation ne marche pas je crois. Donc il faut procéder à une installation manuelle. Voici un lien explicatif pour les intéressé(e)s : http://ph3.defau.lt/index.php/Install(...)

Sous xchat ça change sur tout le serveur. Pour ceux qui utilisent xchat, la ruse est de se connecter deux fois au serveur, une fois en latin-1/9 et l'autre fois en utf-8. Quelques personnes font ça sur #fr.wikipedia et ça fonctionne bien. Sinon des logiciels tels que chatzilla, ksirc, konversation par exemple gèrent un codage par canal. Il existe un module pour irssi afin de faire du transcodage à la volée.
Sinon j'ai noté une grande résistance à l'utf-8 sur un certain nombre de canaux. Ceci venant peut-être du fait que mirc, client propriétaire sous windows ne gère absolument pas l'utf-8. Cependant c'est une bonne occasion pour leur faire découvrir un client libre gérant ce codage. :)

Pour le transfert de la propriété du contenu de Wikipédia à Yahoo, il ne faut pas s'inquiéter. Les articles sont et restent propriété de leurs auteurs respectif et non pas de Wikipédia qui donc même si elle le voulait ne pourrait rien transférer du tout. :)
Sinon, il n'y a aucun accord d'exclusivité avec Yahoo, et ce genre d'opération devrait se renouveler avec de nombreux autres partenaires, rendant Yahoo certes utile, mais non pas indispensable. Des serveurs sont d'ailleurs d'ores et déjà hébergés en France grâce à Lost-Oasis qui sponsorise l'hébergement et une généreuse bande passante (les serveurs français utilisent certains jours pas loin de 3Mo/s en pointe en débit sortant). Les pionniers ce sont donc Lost-Oasis et non pas Yahoo. :)

Alors bien sur, on peut supprimer le "baveux" en utilisant \usepackage{times}

Ou bien tout simplement en installant une fonte de type 1. Acobat 5 gérait mal les types 3. L'amélioration est très sensible avec Acrobat 7. Cependant pour un résultat vraiment impeccable il vaut mieux utiliser des fontes de type 1, là ça passe bien partout. Je vous conseille cm-super disponible sur ctan (http://www.ctan.org/tex-archive/fonts/ps-type1/cm-super/(...) ). Avec ça le computer modern en pdf est superbe et il n'y a pas à ajouter de \usepackage{} supplémentaire dans le source. :)

À l'époque j'avais utilisé un HOWTO de gentoo. Je n'arrive plus à remettre la main sur celui que j'avais, mais voilà quelques liens en vrac. Ça devrait s'adapter assez facilement à n'importe quelle distribution. http://forums.gentoo.org/viewtopic.php?t=166984&(...) http://gentoo-wiki.com/HOWTO_Create_an_UTF-8_enabled_system(...) http://gentoo-wiki.com/HOWTO_Make_your_system_use_unicode/utf-8(...) .

Je n'utilise ni samba ni nfs, donc de ce côté là je ne peux pas te dire grand chose.

Le plus gros du travail consiste en fait à mettre : export LANG="fr_FR.UTF-8" dans le .bashrc (ou autre suivant ton shell). :) Si tu cherches un terminal gérant bien l'unicode, konsole ne pose pas de problème. rxvt-unicode est très bien aussi.

Aussi pour les fans d'IRC, les canaux en utf-8 avec irssi par exemple fonctionnent très bien. :)

À propos de ton site, mon konqueror lit ça comme si c'était en latin-1. Dans mes pages en xhtml je mets quelque chose comme ça <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> pour que ça passe bien. Enfin c'est possible que ce soit une limitation de konqueror qui n'interpréterait pas correctement le <?xml version="1.0" encoding="utf-8"?>

Med

Toutes mes machines sont en utf-8 depuis quelque temps, et pas de problème particulier.

Mes correspondants windows, n'ont pas eu de problème à lire mes courriels. A priori, n'importe quel client mail correct doit pouvoir envoyer les courriels suivant le codage que tu veux. Personnellement j'utilise kmail et automatiquement il utilise le codage le plus adapté (ascii; latin-1/9; utf-8). Le seul problème ça peut éventuellement être les courriels envoyés en utf-8 à des gens qui consultent leur boite par un webmail. Enfin, tu peux forcer en latin-1 pour éviter ça.

Internet Explorer gère correctement l'utf-8. Il y a d'ailleurs un nombre non négligeable de sites qui sont déjà en utf-8, comme http://fr.wikipedia.org(...) par exemple. :)

Pour la conversion de tes tags je ne sais pas. En revanche pour corriger les noms de fichiers, j'avais utilisé mvconv à l'époque de ma migration. Marche bien et rapidement.

De façon générale, ne t'inquiète pas pour l'utf-8, les problèmes sont rares et en constante diminution. Il me semble que red hat et dérivés utilisent par défaut l'utf-8 depuis pas mal de temps. Ça a sans doute permis de défricher un peu.

Personnellement j'avais fait deux mini patchs pour KDE il y a pas mal de temps. Pour les faire intégrer je les ai envoyé directement sur la liste de diffusion correspondante. Ils ont été intégrés dans les heures qui ont suivi. Pour ton cas je pense que la liste kfm-devel (ou quelque chose dans le genre) devrait correspondre. Bonne chance. :)

Ce logiciel a l'air sympa. Les cartes générées semblent vraiment propres.

Dans un genre un peu différent il y a PP3 (http://pp3.sourceforge.net/(...) ). Il a été utilisé pour générer toutes les cartes des constellations de wikipédia, par exemple : http://fr.wikipedia.org/wiki/Constellation_du_Cygne(...) . Il permet de sortir un fichier postscript.

Je ne suis pas aussi sûr que ça. D'après Waldo Bastian (post sur kde-devel du 10 février à 16h05. Les archives n'ont pas l'air d'être accessibles sans inscription à la liste ...) : « DCOP does not depend on X11. DCOP depends on libICE which tends to be shipped along with X11 server implementations but which works perfectly fine in the absence of any X11 server. For various reasons kdelibs itself includes a copy of libICE. »
Il y a aussi ce petit fil sur le dot : http://dot.kde.org/1084186481/1084273331/(...)

Plus exactement, les articles sont sous GFDL au moins, après libre à toi d'ajouter des licences supplémentaires. Pour les images il y a un plus grand choix. Voici une petite liste des licences acceptées et des licences refusées par exemple sur commons (qui se veut strict, pas de faire use ni autres choses dans le genre) : http://commons.wikimedia.org/wiki/Commons:Image_copyright_tags(...) .
Le code de mediawiki (http://wikipedia.sourceforge.net/(...) )est bien sous GPL quant lui

Les détails de l'accord ne sont pas publics. Tout cela est basé sur des spéculations. Du côté de wikipédia le nombre de personnes dans la confidence se comptent sur les doigts d'une main, et mènent activement les négociations. Il faut attendre avant de savoir de quoi il retourne exactement et quelles sont les conditions. Bref, peut-être une bonne nouvelle dans le futur, mais surtout ne pas s'enflammer maintenant.

C'est un DNS développé à l'origine pour un réseau IRC afin que les gens se connectent sur un serveur proche, si je ne souviens bien. J'ai demandé à un des développeurs et il m'a donné ce lien pour ceux qui sont intéressés : http://cvs.blitzed.org/geo-dns/ . À part le README, il n'y a pas de manuel en fait. Si jamais vous voulez lui poser des questions, venez sur #mediawiki (irc.freenode.net) et demandez mark-. Sinon vous pouvez aussi venir sur le canal francophone tant qu'à faire : #fr.wikipedia .

Non. Tu accèderas toujours au wiki que tu veux. En revanche il est possible que tu sois redirigé vers les serveurs français à l'avenir (qui cachent tous les wikis), mais au fond pour toi ça ne change pas grand chose.

Les développeurs pensent à mettre en place GeoDNS qui renverra les visiteurs sur les serveurs floridiens ou bien sur les parisiens selon leur localisation géographique. De cette façon on pourra éviter que les Québécois passent inutilement par la France et ce sera totalement transparent pour les visiteurs.

Plus précisément c'est supposé fonctionner à partir de kde 3.3.2 : http://bugs.kde.org/show_bug.cgi?id=94836(...)

Le travail est presque bouclé sur la partie technique. On va dire que presque tout est en place. En revanche il reste certains problèmes concernant les licences pour les images du wiki anglophone. Beaucoup d'images ne comportent pas de licence. Sur fr: on a fait un gros effort il y a quelques mois donc de notre côté ça va. Je pense qu'on peut espérer sortir avec la 10.2. Enfin je ne suis pas très au courant des accords pratiques avec Mandrake.

Après avoir vérifié en fait il n'y a apparemment qui les dérivés de mozilla qui posaient problème effectivement. Mais comme ça fait une part non négligeable pour nous (typiquement > 10%), ce n'était pas acceptable. Cependant ce serait très agréable que ce problème soit corrigé. Ça permettrait de coder les &nbsp; correctement pour avoir une fenêtre d'édition un peu plus lisible.

Sur wikipedia, on a renoncé à coder les espaces insécables autrement que par &nbsp; (ou équivalents) car sinon des navigateurs (dont mozilla) avaient effectivement tendance à casser les espaces insécables présentes dans une pages lors de l'enregistrement. On a aussi modifié le logiciel pour qu'il remplace les espaces simples par des insécables dans des cas particuliers lors de la génération d'une page pour profiter des espaces insécables tout de même. Par exemple pour « toto », les espaces deviennent des espaces insécables bien que dans le source cela reste des espaces simples.

Vraiment ? Jamais eu ce problème : Centre de configuration/Son et multimédia/Systèmes de sons → Suspendre automatiquement si inactif pendant 0 seconde ... Et voilà arts libère la carte dès que le son est fini. Bien évidemment ça ajoute de la latence lorsqu'un son doit être joué via arts.

Ce n'est sans doute pas exactement ce que tu recherches, mais as-tu essayé de le faire fonctionner avec l'excellent dosbox ? D'après le site cela devrait fonctionner : http://dosbox.sourceforge.net/comp_list.php?showID=61&letter=T(...)

Voici un autre lien sur sa vie : http://en.wikipedia.org/wiki/John_Peel(...)

Il y a une premier problème pratique à tout ca, c'est que Wikipédia relève du droit américain. Si on met des serveurs hors des États-Unis, on tombe aussi du coup sous les lois locales (en oubliant les cas tordus comme l'affaire Yahoo). Quand on voit la peine qu'on a à se conformer à une seule loi ... Sinon, ce qui est en train d'être mis en place, ce sont des squids. Au moins en France, faire du cache est beaucoup plus souple au niveau de la loi. Tout cela permettra d'alléger un peu la charge due aux utilisateurs non logués.
Pour les détails techniques je ne suis pas super compétent. Le mieux serait que tu ailles en parler directement sur IRC avec les développeurs/administrateurs des machines qui connaissent mieux les limitations techniques que moi : #mediawiki sur irc.freenode.net .
Sinon pour l'architecture actuelle, il y a une page plus ou moins à jour qui la décrit : http://meta.wikimedia.org/wiki/Wikimedia_servers(...)

Le problème n'est pas la bande passante, on a en a plus qu'il n'en faut. Wikipedia prend environ 30-35 Mbps en moyenne. En revanche les serveurs sont très chargés la plupart du temps : http://download.wikimedia.org/ganglia/(...) . La lenteur provient de là. Les dons vont surtout servir à acheter de nouveaux serveurs. Pour l'instant le cluster plafonne à environ 800 req/s : http://wikimedia.org/stats/live/(...) . Un phénomène qu'on observe à chaque ajout de nouveaux serveurs est que le nombre de requêtes explose, ce qui fait que le gain réel en vitesse n'est pas aussi important que le gain espéré. Ceci se voit particulièrement bien sur le graphe annuel : http://wikimedia.org/stats/live/org.wikimedia.all.squid.requests-hi(...) tout en bas de la page.