tgl a écrit 1743 commentaires

Puisque la licence du document l'autorise et que s'enregistrer c'est saoulant, j'ai collé là une copie de la version pdf :
http://tdegreni.free.fr/040601_OpenSource.pdf(...)

> Parce que moi, dire machin je l'utilise pas ça pue et ramener ma
> grande g... à chaque fois que son nom aparaît, j'ai passé l'âge...

Mouarf ! J'ai rarement vu une niouze ou un journal abordant Gentoo sans quelques comentaires trollesques de ta part (souvent amusant ceci dit, je te l'accorde).

Gentoo supporte alpha, amd64, arm, hppa, ia64, mips, ppc, ppc64, s390, sparc et x86. Ça fait 11 aussi (sans compter les ports pour les système non-Linux, du type ppc-macos, x86-obsd ou x86-fbsd). Par contre il est tout à fait vrai que suivant l'architecture, tous les paquets ne sont pas disponibles, ou bien pas forcement dans les même versions. En ça, Debian reste effectivement la plus forte au niveau du support multi-architectures.

Après, est-ce que c'est une bonne idée de maintenir à tout prix l'égalité dans le statut des paquets entre toutes ces archis, quite à faire de la distrib un plus petit dénominateur commun, ça se discute (sans fin...).

> Donc si on retire toutes les applis divisees en 12 .deb on doit
> tomber a moins de 6500/7500...

Avec les Sources.gz de main, contrib et non-free, je compte 5589 paquets source (pour 9002 paquets binaires - j'ai pas ajouté non-US). Pour comparer avec Gentoo, c'est effectivement ce chiffre qu'il faut regarder.

> J'ai gagné quelque chose ?

Quelques [pertinent] pour avoir fait tomber un mythe.

Y'a un ebuild qui traine là :
http://bugs.gentoo.org/show_bug.cgi?id=61222(...)
Il est prévu pour la 1.0_rc3, mais une fois renommé slune-1.0.4.ebuild, il marche très bien pour installer la dernière version.

Bon et à part ça, la dernière fois que j'avais essayé Slune, c'était un 0.6.qqch je crois, et ça se finissait bien vite. Et bah il semble s'être considérablement allongé depuis, et est bien sympa, plutôt joli et tout et tout, bref, c'est bon, mangez en.

> Il y aussi la possibilité d'avoir temporairement les deux librairies en
> même temps et de supprimer n'ancienne une fois que tout est
> mise à jours.

C'est en gros l'idée des approches les plus réalistes qui ont été proposées. En gros, on conserverait au fil des installation de paquets compilés un cache de dépendances de librairies. Lors d'une mise à jour libtoto-1.0->1.1, le libtoto-1.0.so ne serait supprimé que si il n'est plus référencé dans le cache. Sinon, il serait conservé et rajouté au contenu référencé par libtoto-1.1, pour être éventuellement nettoyé lors d'une future mise à jour 1.1->1.2 par exemple.

> Mais j'ai peur que certains paquets utilisent l'ancienne
> librairie même s'ils sont reconstruits avec la présence de la
> nouvelle librairie.

C'est un truc auquel il faudrait faire gaffe, mais ça peut être fixé par les ebuilds quand un paquet à tendance à se comporter comme ça, donc c'est pas vraiment bloquant.

Enfin bref, tout ça pour dire que ce problème est effectivement assez naturel sur une distrib source, mais qu'il y aurait moyen de le traiter quand même.


> Ce n'est pas parce que la distribution est binaire qu'elle est figée.
> C'est uniquement une question de gestion de projet.

Oui, je suis plutôt d'accord. Enfin avec un bémol : je pense que l'approche source, parceque justement les dépendances y sont un peu plus souples que celles des paquets binaires, facilite un peu le dynamisme au sein d'une branche stable. Avec des paquets binaires, à cause des dépendances de lib + strictes, tu as plus souvent à faire des commits groupés (typiquement, avec une lib, les programmes qui y sont linkés). Mais ça reste très envisageable, et je pense qu'il y a encore une place à prendre pour une distrib binaire qui ne serait pas orientée releases et qui ne serait pas pour autant une branche de développement. C'est peu être un peu le cas de debian testing, qui si j'ai bien compris passe quand même par une certaine dose de QA, même si elle n'est pas officiellement "stable" (enfin j'dis ça, je connais pas bien, je sais pas par exemple si ils s'imposent que testing soit égale sur toutes les archis ou si, comme gentoo, les différentes archis évoluent chacune à son rythme).

> L'avantage de Fedora, est de pouvoir "tout casser" par moment
> pour avancer vite sans grosse prise de tête avec la compatibilité
> la fiabilité.
> C'est la même chose avec les Linux de numéro impair.

En fait sous gentoo tu peux te permettre ça aussi sur un groupe d'ebuilds que tu hard-masques. Et une fois l'ensemble prêt, les paquets passent en ~arch avec des dépendances qui forcent l'update de l'ensemble tout d'un coup pour rester cohérent. Mais bon, ouais, c'est quand même un peu moins souple.

D'abord, merci d'avoir pris le temps de nous faire part de ton expérience. Ça fait du bien de lire des commentaires sur Gentoo qui ne sont pas truffés d'a priori trollesques (que ce soit des "c'est la distrib la plus rapide du monde" ou au contraire des "c'est une distrib pour les jacky qui se tripent à mater des dump de make pendant des heures").

Quelques petit commentaires en vrac :

Tu ne parle pas du système d'init, je sais pas si tu t'es penché dessus, mais perso c'est un des trucs qui m'avait emballé au début. Pour faire court :
- l'ordre de démarrage des services n'est pas spécifié statiquement mais calculé en fonction de leurs besoins spécifiques (chaque script déclare des "need machin", "after truc", etc.). C'est joli et simple à utiliser. Cerise sur le gateau, ça a permis de facilement ajouter la parallélisation des démarrages de services il y a maintenant un bout de temps (ce qui n'a pas un grand intérêt, mais bon, pourquoi ne pas le faire puisqu'avec ce système c'était simple);
- on peut créer autant de runlevels qu'on veut, ce qui est bien pratique pour jongler dans les configs réseau par exemple, ou bien se faire un mode maintenance moins frustre que le single user, ou démarrer simplement l'ensemble des services dont on a besoin pour bidouiller son site web, etc. C'est vachement + souple que les 2 ou 3 niveaux d'init disponibles sur la plupart des distribs.
Tout ça en détails ici : http://www.gentoo.org/doc/fr/handbook/handbook-x86.xml?part=2&c(...)

Un autre point super important de la ditrib, c'est sa notion de "stabilité" qui est bien différente des distribs fonctionnant par releases globales. On a sous Gentoo des releases, certes, mais qui concernent uniquement les CD d'install, les stages, et les profiles. Les paquets par contre sont tous traités individuellement via leur KEYWORDS, avec au final une distrib "stable" en permanente évolution (et différente sur chaque archi). C'est vraiment une différence fondamentale avec la plupart des autres distribs. Bon, on aime ou on aime pas, on a confiance en ce système ou pas, ça c'est à chacun de voir, mais je crois que c'est vraiment un truc qui est décisif pour adopter ou non Gentoo.

Niveau points faibles, y'a un truc dont tu n'as probablement pas eu le temps de faire l'expérience, c'est que le système de dépendances sur les paquets sources est plus faible que ce qui se fait sur des binaires. Il représente ce qui est nécéssaire pour compiler, mais une fois le paquets compilé, il peut avoir des dépendances de runtime plus strictes (typiquement, un paquet nécéssitant "libtoto-1*" peut compiler sans pb avec libtoto-1.0 ou libtoto-1.1, mais une fois linké à libtoto-1.0.so, sa dépendance devient plus précise, et une mise à jour de libtoto en 1.1 pourra le casser). Ça c'est un truc que Gentoo ne prend pas bien en compte. Y'a bien un outil pour rebuilder les paquets qui se retrouvent cassés de cette façon, mais c'est vraiment pas une "solution". Y'a plusieurs approches possibles pour faire prendre ça en compte à portage, mais c'est une modif assez fondamentale, donc je sais pas si ça va venir de si tôt.

À propos d'etc-update, c'est vrai qu'il est assez frustre, mais il y a mieux : "dispatch-conf". Celui là rempli la même tâche, mais ajoute :
- un système de backup avec gestion de versions de tes fichiers de conf (basé sur RCS ou bien sur un gros paquet de "fichier.version", au choix),
- la mise à jour automatique des fichiers qui sont encore dans leur état par défaut
- une assistance au merge entre ta conf courante et le nouveau fichier par défaut, basé sur "diff3" (prenant en compte donc l'ancienne configuration par défaut pour identifier ce que tu as changé/ajouté et faire la même modif sur la nouvelle configuration par défaut)

Sur les infos qui se retrouvent perdus dans les logs de compil', c'est effectivement un pb, mais y'a pas mal de solutions. Y'a par exemple différents petits scripts qui vont parser les logs à leur recherche, genre ça :
http://tdegreni.free.fr/gentoo/portlog-info(...)
Y'a aussi des patchs pour emerge qui trainent avec des solutions diverses (rapporter les messages à la fin des compil, ou les mailer au root, ou cacher le dump de make, etc.). Par exemple :
<blink>pub</blink> http://bugs.gentoo.org/show_bug.cgi?id=37491(...)
En fait il serait vraiment temps que les mainteneurs de portage se décident pour une solution, parceque c'est une requête récurrente et justifiée.

Concernant le temps bouffé par les compilations, bof, faut voir, c'est pas forcement un problème. Bon perso ça me dérange carrément pas, c'est une tâche de fond qui remplace très bien un seti@home, et puis voilà. Mais même sans être aussi tolérant, on peut pas mal réduire la chose. Gentoo sort régulièrement des paquets binaires, qu'on peut utiliser pour faire une installation initiale rapide. C'est une assez bonne approche en fait : tu as très vite ta distrib utilisable, et après tu réinstalles from sourfces au fur et à mesure où les besoins s'en font sentir des paquets avec des USE flags personnalisés. Au bout de qlqs temps, tu as une distrib bien à toi, sans pour autant être jamais passé par la case grosse compil' de 48H.

Concernant «l'intérêt de la chose», bah... question de goût quoi. Moi j'aime bien, c'est une distrib qui est très souple mais pas inutilement compliquée pour autant, qui m'a toujours permis de faire tout ce que je voulais comme je le voulais sans grosse prise de tête.

Perso ce qui m'a gêné le plus, c'est comme l'a dit gc la proximité de la dépêche précédente, d'où mon vote contre. Pour moi, ton bouquin a déjà été présenté il y a moins d'un mois, même si il n'était pas commandable à l'époque. Il a eu son coup de projecteur, et maintenant que c'est fait, il suffisait aux gens que ça intérresse de surveiller ton site pour savoir quand il serait dispo à la vente. Mais je considère que ça n'est pas à linuxfr de relayer ce genre de détail.

On ne peut tout simplement pas faire un suivi de tout ce qui a été mentionné un jour sur le site. C'est pareil avec les projets logiciels : il arrive souvent que, suivant les aléas des dépêches proposées, un petit soft sympa soit présenté dans sa version 0.9.1_pre, mais ça n'engage pas pour autant linuxfr à prévenir tout le monde quand la 0.9.1 sera dispo, puis la 1.0, etc., surtout si tout ça se passe dans un intervale de qlqs semaines.

En tout cas, soit bien assuré qu'il n'y a aucune obscure magouille dans mon vote, et que dans plein d'autres situations j'aurais été pour la publication. Il aurait suffit qu'il n'ait pas déjà été présenté, ou bien que ce soit suffisament vieux (qlqs mois) pour qu'on je juge nécéssaire la piqure de rappel, ou encore que la dépêche apporte un contenu significatif (par exemple que ce soit une critique du livre par un de tes premiers lecteurs), ou que le bouquin soit libre (bah ouais, perso je suis plus indulgent dans ces cas là), etc.

> Le modérateur (anonyme en cas de refus)

Le refus est une décision collégiale de l'équipe de modération / relecture, et je ne vois pas ce qu'apporterait la publication du nom du modéro qui l'exécute là dedans.

> m'a répondu que mon article était hors sujet et que de plus il ne
> désirait pas de publicité !

Perso je trouve que c'est un problème du système de modération actuel que le "pourquoi" d'un refus soit un truc écrit uniquement par le modéro qui l'exécute, et qui ne correspond pas forcement aux motivations des gens qui ont voté. Je préfererais un système où tous les modéros et relecteurs pouraient laisser pendant la phase de modération, s'ils le souhaitent, leur petit commentaire bien à eux, et que le tout soit transmis en cas de refus. Ça réduiraient je pense fortement les messages purement automatiques ou les résumés un peu déformant, dont tu n'es effectivement pas le premier à te plaindre, et de mesurer combien souvent les opinions sur une dépêche sont variées et mitigées, enfin bref, ça serait moins sec.

> par contre aïe les yeux à cause de la fréquence à 60 Hz

Vesafb-tng est fait pour toi :
http://dev.gentoo.org/~spock/projects/vesafb-tng/(...)

Dans le genre transparents+explications, y'a aussi la solution logidee qui est sympa, vraiment pensée pour l'enseignement ou la formation. C'est en gros : une DTD, des feuilles XSLT, et un Makefile qui s'occupe de la transformation de la source XML vers différentes versions LaTeX (slides, slides en 2 par page, polycopié, etc.) puis de leur compilation en PDF. Et c'est bien documenté.
http://www.logidee.com/tools/(...)

Tiens, ça a l'air mort... On trouve encore le tarball chez debian :
http://packages.debian.org/testing/text/logidee-tools(...)

> le fait qu'un des paquets n'ait pas les bonnes dépendances me
> choque un peu

Bah c'est en effet regrettable, mais pas si étonnant. Je trouve que les dépendances de build sont souvent plus dures à déterminer que celle de runtime. Elle sont en général moins documentées, elle ne sont pas analysable à coup de ldd et compagnie, et elles sont généralement satisfaites sur les machines de n'importe quel développeur, donc discrètes. Ajoute qu'un bug comme tu as eu, facile à contourner (« Il veut machin ? Bon alors j'emerge machin. ») et qui n'arrive probablement qu'au mauvais moment (càd pendant une install fraiche), a très peu de chances d'être rapporter, et ça explique assez bien comment ça a fait pour atteindre un ebuild stable.

> grâce à USE, tu peux tuner les compilations et avoir des choses
> moins grosses que sur les autre distribs :)

Y'a du vrai et du faux.

Du vrai parceque :
- les USE flags permettent effectivement de sélectionner parmis les options de compil' et donc de ne pas se retrouvé linké à 36 libs dont on se moque (là où avec des paquets binaires, le choix est entre les mains du mainteneur qui cherchera un compromis acceptable pour la majorité des utilisateurs, mais qui ne sera idéal pour personne). Avec l'influence que ça a sur les dépendances, c'est non négligeable comme gain ;
- le choix de cflags de type -Os permet de grapiller sur la taille des binaires (bon, ça ça reste minime) ;
- parcequ'une utilisation judicieuse des profils, de la cross compilation et des paquets binaires permet par exemple de s'installer une gentoo uClibc sur un flashdrive dans un routeur mini-itx (c'est le côté "méta-distribution" : au lieu de répondre à chaque type de besoin par une distrib différente, on spécialise une unique base de distrib). Bon, ça sort du cadre de l'utilisation de base, mais pas de doute, faire des très petites gentoo est possible et relativement pratique (y'a des choses à améliorer au niveau de portage pour la prise en compte de la cross compil cependant, mais là je vire HS).

Du faux parceque :
- l'utilisateur de base qui n'a qu'une machine et qui veut l'utiliser uniquement comme station bureautique aura besoin de plus de place, temporaire (espace de compil', arbre portage, tarballs des sources, ccache, etc.) comme permanente (chaine de compil', headers, etc.) avec une distrib sources qu'avec une distrib binaires ;
- les USE flags sont en général utilisés en gros pour commander des options de ./configure ou ajouter des petits addons comme de la doc, etc. Par contre, il sont très peu utiliser pour descendre en deça de la granularité choisie par les développeurs des logiciels. Ainsi, si tu as juste besoin de smbmount sur ta station, tu installeras quand même tout samba sous gentoo, parceque c'est comme ça que c'est distribué. Les distribs binaires au contraires vont en général faire un découpage en plusieurs sous-paquets (un seul .srpm te créée souvent toute une collection de .rpm, et pareil pour les .deb, etc.). Remédier à ça sous gentoo demanderais des changements non triviaux sur Portage pour pouvoir être bien fait, et je n'ai pas l'impression que ce soit du tout une priorité.

> je fais les compilation sur une partition à part

Ah j'avais pas compris ça. Dans ces cas là, oui ça passe probablement.

> Concernant ton opinion sur mon "test"

Ouaif ça ne t'étais qu'à moitié destiné en fait, c'est plus une remarque générale parceque je vois souvent des tests d'install annoncés comme des tests de distrib, ou des gens qui par abus de langage disent "j'ai testé mandrake hier soir". À chaque fois je tique, alors fallait que ça sorte :)

> Rien ne me choque dans ton CLFAG

Enfin sauf que c'est absurde d'avoir un march plus précis que le mcpu (je veux dire que "-march=i686 -mcpu=athlon-xp" ça fait sens, mais pas l'inverse), mais sinon effectivement ce serait étonnant que ça suffise à faire délirer gcc. Je penche aussi pour la mémoire pourrie ou le proc qui chauffe, on en voit _vraiment_ souvent sous gentoo, et chez des gens qui ne s'en était pas rendu compte avec leurs précédentes distribs. Le materiel, ça suxxor.

À part ça, 3,5 Go pour une gentoo de bureau ça ne me semble pas super viable : oui, une gentoo, c'est vite gros. Là où les autres distribs se passent très bien d'un environnement de compilation, la gentoo en a besoin. Là où les autres distribs ne téléchargent que les binaires des paquets, la gentoo à besoin de l'espace pour le tarball des sources, pour sa compilation (compter >2Go pour openoffice !), éventuellement pour le ccache (/!\ activé par défaut il me semble) et pour l'installation enfin biensûr, qui peut elle aussi être plus volumineuse qu'ailleurs (parceque d'une part les gens utilisent souvent des cflags qui font gonfler les binaires, et d'autre part, surtout, les paquets ne sont pas découpés après compil' comme sous d'autres distribs, ce qui fait qu'il n'est pas toujours offert de n'installer que le client d'une appli client/serveur par exemple). Enfin c'est peut-être jouable, mais va falloir faire bien gaffe au ménage, tout ça quoi...

Enfin, remarque plus générale encore, je ne crois vraiment pas qu'on puisse "tester" des distribs comme ça en quelques jours sur l'install et la config de base. Enfin si, mais ce qu'on teste alors ça n'est pas la distrib mais juste son accessibilité pour le nouvel utilisateur, c'est à dire seulement un aspect très particulier (même si c'est intéressant quand il s'agit de savoir que recommander à papa qui a décidé de se mettre au libre). Perso, j'ai toujours eu un regard vraiment très différent sur les distribs par lesquelles je suis passé après qlqs mois d'utilisation, et pour ça j'aurais trouvé présomptueux de les juger sur mes premières impressions.

Deux "gros" logiciels que j'aime bien en OCaml :
- mldonkey (client de p2p avec une architecture client/serveur et différents front-ends) :
http://www.nongnu.org/mldonkey/(...)
- unison (outil de synchronisation de fichiers, et plus encore) :
http://www.cis.upenn.edu/~bcpierce/unison(...)

Pour une liste un peu plus large :
http://caml.inria.fr/users_programs-eng.html(...)

Bah là ça dépend vraiment du portable. Sur mon T40, ça marche out-of-the-box en hard (via les raccourcis clavier, directement géré par le bios), et c'est censé marcher un jour en soft via le module ibm-acpi.

Mais sur ce genre de truc, y'en a vraiment pour tous les goût parmis les constructeurs et les modèles, donc ça n'est qu'en fouinant sur tuxmobil.org ou linux-laptop.net que tu as une chance d'avoir ta réponse.

Par contre j'ai l'impression que sitôt qu'il y a un index.html, tu fais ce que tu veux derrière. Perso j'ai mon compte depuis des années avec le même index.html d'une ligne, qui me sert uniquement d'espace de stockage/partage, mais je me suis jamais rien fait supprimer. Bon, c'est pas des fichiers audio ou video en général, alors peut-être que leurs scripts sont moins regardants dans ce cas là.

Dans la NdM de remerciement que j'ai rajoutée à cette niouze, je t'ai désignée comme la geekette de remat. On me glisse dans mon oreillette que ça ne t'as pas plu, et en y repensant je peux effectivement très bien le comprendre. Je te présente donc mes plus plates excuses. Mon intention avec cette note était simplement que tu saches qu'on avait apprecié ta contribution, et qu'on t'en était reconnaissant.

Bon, j'ai pas tout raté, puisque tu as compris qu'on parlait de toi... Mais en quels termes ? Pourquoi la geekette de remat ? Et bien principalement par précipitation : j'ai fait avec ce que j'avais comme infos sous la main et sur l'instant, sans y accorder ces quelques minutes supplémentaires qui suffisaient pourtant à trouver ton prénom et ton pseudo (comme parfois je remercie "toutes les personnes ayant proposé des dépêches similaires", sans prendre la peine de les lister nommement). Par maladresse aussi : le mot geekette, il est venu comme ça, parceque les trucs en -ette ça sonne sympathique, et que ce que je connais de remat c'est le geek, et puis donc zou, tu étais sa geekette. Un choix plus phonétique qu'autre chose en fait, et en tout cas bien inconscient de son éventuelle connotation péjorative.

Je te remercie encore pour ces traductions, et j'espère qu'en comprenant que c'était bien là déjà ma seule intention, tu pardonneras ces erreurs de forme.

Par pitié allez continuer cette discussion sur un autre comptoir.

Boh allez, sois pas chien, tu va bien nous remettre un p'tit ballon pour la route avant d'nous foutre dehors.

"noatime" ne pose certainement pas problème, par contre tu peux essayer en virant "users", je serais pas hyper surpris que ça aide (je parle là de la partoche où est /var/tmp biensûr).

Elle ressemble à quoi ta fstab ? J'ai déjà vu ce genre de symptome à cause d'options "noexec" ou assimilé sur la partoche /var par exemple.

En lisant la niouze, j'ai eu peur qu'il ait pompé un logo PLF, ça aurait fait mauvais genre, mais non, ça va :
http://www.inthebullpen.com/images/articles/hacked.jpg(...)
Ceci dit j'ai quand même l'impression d'avoir déjà vu ce dessin, mais je sait plus où.

> c'est destine a transformer un arbre xml en un autre [...], pas a faire
> des "programmes"

C'est quoi pour toi un programme ? Le même traitement codé en C serait-il un programme ?

> Je ne sais pas si la pétition sur la "qualité des produits
> Mandrakelinux" a été annoncée sur le site de Linuxfr.org

Oui, là en l'occurence :
http://linuxfr.org/forums/14/3887.html(...)

Bon bah ça merdouille ici pareil, j'ai des blancs à la place des accents. Un coup d'épée dans l'eau donc, et j'avoue que j'ai pas d'idée. J'ai essayé de faire qlqs pdf depuis OOo avec diverses polices, et je n'ai pu reproduire aucun bug similaire.

J'avais pas mal de pb d'affichage ou de police avec gpdf (0.13qqch) qui se sont réglés quand je suis passé à gnome-2.8 et gpdf-2.8. Tu utilises quelle version ? Aurais-tu un document d'exemple qui merdouille chez toi pour que je teste ici ?