Boa Treize a écrit 3450 commentaires

s/admettent/affirment/

Même l'ANPE a fait mieux ! (Non, je n'ai pas de lien sous la main.)

« Chez moi, ça marche. » ®

$ wget -c http://download.berlios.de/mldonkey/g2gui-0.2.1-linux-shared-gtk.ta(...)
--16:43:40-- http://download.berlios.de/mldonkey/g2gui-0.2.1-linux-shared-gtk.ta(...)
           => `g2gui-0.2.1-linux-shared-gtk.tar.bz2'
Resolving download.berlios.de... 195.37.77.141
Connecting to download.berlios.de[195.37.77.141]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4,875,254 [application/x-bzip2]

100%[====================================>] 4,875,254 61.78K/s ETA 00:00

16:44:59 (60.87 KB/s) - `g2gui-0.2.1-linux-shared-gtk.tar.bz2' saved [4875254/4875254]

$ ls g2*
g2gui-0.2.1-linux-shared-gtk.tar.bz2

Peut-être n'as-tu plus d'espace disque ou d'inodes libres ? « df » et « df -i » pour vérifier. C'est quand même bizarre qu'il t'ait tout téléchargé.

Ah, je remarque que tu avais repris le téléchargement. Il y a peut-être un problème à ce niveau ?

Dans le genre, il y a le concours du plus petit Wiki : http://c2.com/cgi/wiki?ShortestWikiContest(...)

Je l'ai découvert par l'intermédiaire de WyPy, un des concurrents, dont le code source est quand même pas mal « Obfuscated ».

Version originale :
http://infomesh.net/2003/wypy/wy.py.txt(...)

Version en production :
http://infomesh.net/2003/wypy/wypy.py.txt(...)

Tester la version en production :
http://sbp.f2o.org/2003/wypy(...)

Vu sur le wiki dans le registre des archives Arch (http://wiki.gnuarch.org/moin.cgi/Archive_20Registry(...) ) :

• Édouard Gomez se sert d'Arch pour travailler sur XviD, TLA et le pilote SpeedTouch.
• David Mentre se sert d'Arch pour travailler sur DemExp (Democratic Experiment).

Le tutoriel est peut-être bien trop complet, et en tout cas destiné à des dévelopeurs, pas à des gens qui veulent simplement récupérer une archive existante et travailler un peu dessus ou tout simplement compiler le code. Le wiki est pour ça bourré d'excellents tuyaux :

Introduction rapide (pour ceux qui ont besoin de travailler sur un projet préexistant) :
http://wiki.gnuarch.org/moin.cgi/Quick_20Introduction(...)

Recettes Arch (comment effectuer au mieux les opérations les plus courantes) :
http://wiki.gnuarch.org/moin.cgi/Arch_20Recipes(...)

Référence TLA (basé sur l'aide de TLA, mais en plus verbeux et avec des exemples) :
http://wiki.gnuarch.org/moin.cgi/Tla_20Reference(...)

Malheureusement, tout ceci n'est pas forcément 100% complet (mais c'est pas mal avancé quand même, hein) et surtout tout en anglais. J'ai vu qu'un courageux avait commencé à traduire la page d'accueil du wiki cet après-midi, rien ne vous interdit d'aller traduire ces autres sections (mais elles risquent de pas mal évoluer - problème et avantage des wikis).

tla est également capable de n'appliquer que les patches nécessaires lorsque tu fusionne le changeset de quelqu'un d'autre. Il se souvient de tous les patches appliqués, et ne prend que les nouveaux. Outre son côté distribué, un des points forts de Arch est sa capacité à fusionner les changesets. De très nombreux modes de fonctionnement et options sont disponibles, afin de rendre cette opération très fréquente la moins pénible et la plus sûre possible.

Les alternatives sont peut-être encore un poil trop jeunes et n'ont pas atteint la masse critique d'utilisateurs pour que Linus Torvalds s'y essaye. Ceci dit, les développeurs du noyau sont tout à fait au courant de leur existence, certains les utilisent, et des utilisateurs de Arch (et de subversion certainement) font du lobbying en ce sens, et travaillent à améliorer Arch (et Subversion certainement) pour qu'il soit le plus adapté possible au développement du noyau. Il est clair que si|quand un des deux systèmes est|sera choisi de préférence à BitKeeper, il gagnera énormément en crédibilité.

Je voulais parler des miroirs du site FTP de GNU. (Il n'y a pas de site français dans cette liste : http://wiki.gnuarch.org/moin.cgi/Official_20releases(...) .)

Oui, mais pas moi. ;-)

• Tous ceux qui travaillent sur tla en sont très contents, bien sûr.
• Les auteurs de MoinMoin en sont très contents.
• Les forkeurs de Xouvert, je sais pas.

Il y a certainement pas mal d'autres personnes qui ont une expérience d'utilisation de l'utilisation de arch, mais je les connais pas.

Bon l humour cela ne te touche pas.

Excellent ! :-D

C'est ici que ça se passe :
http://wiki.gnuarch.org/moin.cgi/Official_20releases(...)

Et plus globalement, ici, pour les packages et les tarballs quotidiens :
http://wiki.gnuarch.org/moin.cgi/Getting_20Arch(...)

Au fait, il n'y a plus de miroir GNU qui marche en France ?

Est-ce qu'elles ne se sont pas plutôt dégradées avec l'accroissement du succès du site ? Ou avec le passage à Templeet ? Ou le passage à Mozilla ? Ou le passage à l'an 2000 ?

Héé oui, on grandit tous un jour. On finit par faire le tour du sujet, et on passe à autre chose. Le principal, c'est que plein de jeunes y croient encore.

pourquoi avant il était où ? dans ftp://ftp.proxad.net/pub/Games/(...) ?

Ta vision du monde est pour le moins déformée. Enfin bon, à chacun son délire, hein ?

La GPL non plus. ... ... Ne pas utiliser la GPL ?

Ça veut dire que personne ne peut faire du pognon avec ton oeuvre sans ton consentement écrit (en la vendant directement, en vendant quelque chose qui la contient de quelque manière que ce soit, etc.).

Pas mal comme résumé, et une bonne conclusion. Il y a toutefois quelques points qui me semblent erronés :

new drivers cannot be released without re-releasing the whole package

Très mal dit. On peut tout à fait sortir de nouvelles versions des pilotes ou de nouveaux pilotes, et les distribuer sous forme pré-compilée. Il faut quand même faire une version par architecture et version majeure de gcc, mais ça reste gérable. Pour preuve le pilote SiS dont une nouvelle version sort tous les deux ou trois jours, ou les pilotes du projet DRI qui sont recompilés chaque nuit à partir de leur CVS. Comme quoi, XFree86 n'est pas tant « non-modulaire » que ça.

Par contre, pour compiler soi-même le pilote, il faut effectivement une copie complète des sources de XFree86, c'est lourd.

it seemed that the announcement [comme quoi XFree86 et X.Org s'étaient rapprochés] was probably not very meaningful, but it is a reflection of the turmoil surrounding X development and the efforts of some to reform the organizations involved

C'est surtout un signe que tout pet de travers de la part de XFree86 est immédiatement amplifié et déformé. Dans ce cas précis, XFree86 a accru sa crédibilité et sa reconnaissance de la part de l'industrie en devenant Membre Honoraire de X.Org, c'est à dire membre sans avoir besoin de raquer. En d'autres temps, ç'aurait été très bien accueilli (comme il se doit).

The packaging of Xlibs, in some ways, was the most significant development over the past year. For the first time, actual work had been done, and code was ready.

Ça sous-entend qu'aucun boulot n'est fait sur XFree86 depuis des années, et que heuseusement qu'en quelques mois des développeurs ont pu faire du vrai travail. La vérité, c'est qu'effectivement aucun travail n'avait été fait sur XLib depuis longtemps, mais la formulation généralise ce fait à l'ensemble de XFree86.

Un mix infâme entre un vieux langage (très bon au demeurant) qu'était le C

Mwaha ahahaha ! Le C, un « très bon » langage ?! :-D

... et pas toujours possible. On est français, oui ou zut ?

<troll mode="food-for-thought">Peut-être, mais au moins c'est plus corporate-beginner-friendly</troll>

<troll mode="food-for-thought">Parce que le but de GNOME n'est pas de laisser le choix à l'utilisateur, mais de créer une interface unique à même de rendre les corporate users plus productifs et le support technique RedHat moins onéreux.</troll>

C'est d'ailleurs une des grandes questions que je me pose sur les interfaces graphiques sous Linux : comment font-il pour avoir besoin d'autant de surface écran pour afficher somme toute peu d'informations ?

Une bonne partie du problème vient qu'ils travaillent en version anglaise, où la taille des boîtes de dialogue est manifestement beaucoup plus acceptable. Si tu regardes bien, tu verras que souvent une boîte de dialogue a une taille monstrueuse parce qu'un ou deux boutons françisés ont un texte très long. Du coup le bouton est très large, la colonne de boutons est très large, la fenêtre est très large... en français seulement. Ça n'explique pas tout, mais ça explique une bonne partie de l'horreur que j'ai dû subir lors du passage à KDE 3.2 (par exemple configuration KMail en 1200x1000 à peu près, avec un gestionnaire de fenêtre qui refuse que la barre de titre soit hors de l'écran... bonne chance pour cliquer sur Ok en bas de la fenêtre, et vivent les raccourcis clavier !). Autre chose qui n'aide pas, j'utilise des polices relativement grosses (taille 12 sans interpéteur de microcode TrueType), donc forcément la fenêtre prend plus de place que lorsque le développeur l'a créée.

Je confirme que vous avez bien lu ce que j'ai dit au début

Oui je l'ai bien lu, mais non je ne le confirme pas. Arch ne crée pas des fichiers .rej comme patch, les fichiers .rej sont créés par patch, car Arch fait directement appel à patch, comme le supposait xd, ce que j'ai confirmé.