tgl a écrit 1743 commentaires

Pour suivre l'avancement de la chose, on peut se surveiller les dépendances de ce meta-bug :
http://bugs.gentoo.org/showdependencytree.cgi?id=117482
Ça fait finalement assez peu de problèmes pour les gcc-4.x je trouve (comparativement à tout ce qui marche déjà bien quoi).

M'enfin... Je garde espoir, sachant que c'est surtout le code de certaines appllis qui ne compilent pas avec GCC 4 qui fait que le support officiel tarde.

Tout à fait. Pour enfoncer encore un peu le clou, disons qu'il n'est pas vraiment question que gcc4 atteigne le ~arch tant qu'il restera des problèmes connus avec certains paquets qui sont fonctionnels par ailleurs. La branche ~arch n'est pas un terrain de jeu où l'on a le droit de sciemment provoquer des régressions, mais c'est une branche pour les paquets candidats à la stabilité. Aux imprévus près, elle est censée être complètement cohérente, enfin autant que possible.

Perso, je trouve ça plutôt rassurant que les devs Gentoo se tiennent à cette politique, y compris pour des paquets où la demande populaire peut devenir, comme ici, assez pressante. Et puis bon, c'est pas non plus comme si les ebuilds étaient absent de Portage et que ça prenait plus d'une dizaine de secondes pour y avoir accès...

Oops, merci, corrigé.

Ceci dit, je crois pas qu'on puisse comparer ces distributions de GNU/Hurd avec la plupart des ports Gentoo qui sont des ports d'un simple système de paquet sur un système totalement différent (Portaris pour Solaris, etc.).

Le portage de Gentoo pour BSD, je pense que si, il représente un travail assez similaire au portage de Debian pour GNU/Hurd. Ils ne s'agit pas simplement de faire tourner "emerge", ça c'est rien, ou presque... Il faut aussi largement modifier le système d'init, adapter la toolchain, fixer les multiples petits problèmes qui apparraissent dans les différents paquets, et enfin, dans ce cas précis, nettoyer où nécessaire la distrib' et les ebuilds de leurs GNUismes, puisque ce sont les versions BSD des commandes de bases qui sont préferées.

Bon maintenant, c'est clair que ça va plus vite qu'un portage pour Hurd : là où Debian défriche, Gentoo elle profite d'un existant déjà bien établi pour les BSD, avec beaucoup plus de sources déjà fonctionnelles, ou encore de nombreux patchs déjà disponibles dans les ports. C'est évidemment une énorme différence, mais elle est plus quantitative que qualitative à mon avis.

Quant au portage pour MacOSX, là effectivement c'est fondamentalement différent, puisqu'il ne s'agit de faire un OS complet, mais de se greffer sur un machin déjà existant et fonctionnel (ce qui au passage amène son lot de contraintes aussi, mais bon, c'est pas les mêmes). Mais même là, parler d'un simple portage du système de paquet me semble assez réducteur. Le gros travail, il est sur les paquets. Pour info, il y a en ce moment dans l'arbre Portage 1262 ebuilds qui utilisent le flag "macos" pour changer leur comportement, genre appliquer des patchs, etc. C'est pas monstrueux, mais c'est du boulot quand même. Et à ça il faut ajouter tous ceux où ont été faits des changements inconditionnels, ainsi que tout ce qui a déjà intégré upstream (non, j'ai pas de chiffres).

Bon par contre, c'est vrai que, là encore, le travail déjà effectué par les gens de Fink aide évidemment considérablement. (Note d'ailleurs que, dans le cas de Fink aussi, je doute que le portage de dpkg et apt ait représenté, proportionellement, une part bien considérable du travail globalement fourni.)

Et enfin, Portaris, bah j'ai jamais regardé, donc aucune idée de ce qui a été fait et de ce que ça représente comme taf.

Dans le cas de gentoo, c'est quand meme une distrib qui s'inspire des ports BSD donc c'est quand meme moins évident de voir un réel interet.

- ça n'est pas parceque X s'inspire de Y qu'il est déraisonnable de préférer X à Y (au contraire même, quand dans le libre on s'inspire de quelque chose, c'est souvent parcequ'on pense pouvoir l'améliorer) ;
- une distrib', qu'elle soit Linux ou BSD, ça ne se résume pas à un système de gestion des paquets, loin de là (cf. la variété parmis les distrib' Linux à base de .rpm ou de .deb, par exemple).

Je vais peut-être avoir l'air un peu mal comprenant mais enfin, ça sert à quoi de porter Gentoo sur FreeBSD ? Pourquoi ne pas utiliser tout simplement FreeBSD ?

Bah, c'est large comme question, c'est un peu comme si tu demandais « À quoi ça sert Gentoo Linux, pourquoi ne pas plutôt utiliser Debian Linux ? ». C'est vrai que dans le monde *BSD, la tradition est de n'avoir qu'une distribution par noyau, mais pourtant rien ne s'oppose a priori à changer cet état de fait, et un peu de variété n'y serait probablement pas plus mal venue ou incongrue qu'elle ne l'est dans le monde Linux.

L'objectif pour les développeurs est, ici comme ailleurs, de faire le système qui leur semble idéal : noyau et commandes de base BSDistes d'un côté, et système d'init, gestionnaire de paquets, et autres outils d'administration Gentooesques de l'autre. Bref, de leur point de vue, le meilleurs des deux mondes.

Après, ça reste bien sûr une affaire de goûts et d'habitudes, et quelqu'un qui préfèrerait, par exemple, le système des ports FreeBSD à celui des ebuilds de Gentoo/Portage n'aurait évidemment aucun intérêt à changer de crèmerie.

À signaler aussi dans l'actualité de Gentoo les progrès du port de la distrib' sur FreeBSD 6.0, fruit du travail de l'infatigable Diego Pettèno :
http://planet.gentoo.org/developers/flameeyes?cat=59
Un stage x86 et une image VMWare de cette distribution sont d'ailleurs disponibles au téléchargement sur le tracker Bittorent sus-pointé.

Bon, perso je connais pas grand chose aux *BSD, et je ne sens aucun besoin particulier de m'éloigner de Linux, mais là quand même je crois que je vais faire une petite place à ce système, ne serait-ce que par curiosité, et pour faire honneur à l'énergie que son mainteneur y dépense.

> grep "maclé=" monfichier | sed -e 's;^maclé=;;g'

Pas besoin d'un grep, il suffit de dire à sed de n'afficher que la ligne qui nous intéresse :
% sed -n -e "s/^maclé=//p" mon fichier

> cela permet aux personnes débutantes ou frileuses de tester sans
> risque les différentes distributions.

Bah, je suis pas vraiment d'accord. Enfin, j'apprécie moi aussi, pour d'autres raisons, les LiveCD, mais par contre ça ne me semble vraiment pas être la bonne façon de tester des distributions dont la vocation première est d'être installées :
- quand qqch ne nous plait pas (ex: Gnome à la place de KDE), ou ne fonctionne pas (ex: un driver wifi qui manque), ça ne laisse rien présager sur la version installable, où l'on peut faire des choix d'installation et corriger les problèmes éventuels.
- si ça donne une idée sur les logiciels (applications, environnement de bureau, etc.) proposés par la distrib' (et encore, une idée vraiment très partielle), ça ne donne par contre aucune idée ou presque sur son administration, sa maintenance au jour le jour, sa facilité/difficulté d'installation, la disponibilité de ses mises à jours, la réactivité de sa communauté, etc., qui sont pourtant autant de critères de comparaison beaucoup plus pertinents.

Enfin bref, non, je ne vois vraiment pas trop ce qu'on peut conclure quant à une distribution après un simple test de son LiveCD, et ça me paraitrait bien hasardeux de faire des choix sur cette base.

> est-ce qu'il ne faudrait pas ajouter les "contre" et les "secondes pages" ?

Non. Je crois que je n'ai pas voté sur cette niouze, mais si je l'avais fait, ça aurait été [contre] pour demander un rerédaction... mais avec en tête une publication en 1ère page, et même en l'état, je trouve qu'elle y a sa place.

De manière générale, il ne serait pas absurde de distinguer le vote pour/contre du vote 1ère/2nd page, ou d'introduire d'autres subtilités de ce genre. Mais bon, y'a pas grand monde pour se coller là dessus, et on s'en tire correctement sans en général, donc voilà quoi, ça peut rester imparfait...

Le --exclude tout court quant à lui, c'est pour lister des chemins ou patterns à exclure directement.

Il n'y a pas d'opérateur de redirection ">>&" (ou "&>>"). Bon ceci dit si ça t'embête de faire des redirections ligne par ligne, tu peut toujours faire qqch comme ça :

% cat plop.sh
#!/bin/bash
log_on() { exec 3>&1 4>&2 1>>/tmp/plop.log 2>&1 ; }
log_off() { exec 1>&3 2>&4 3>&- 4>&- ; }
echo plup
log_on
echo coucou
ls coucou
log_off
echo plip

% ./plop.sh
plup
plip

% cat /tmp/plop.log
coucou
ls: coucou: Aucun fichier ou répertoire de ce type

> Dans le cas des liens que tu cites, une telle navigation reviendrait à
> présenter "au niveau zéro" tous les tags existants et ensuite filtrer
> par association de tags

Non. Tu n'as pas assez lu je pense, ou peut-être que parceque la terminologie n'est pas la même que la tienne certains points t'ont échappé.

Soyons pratiques... Il suffit de rentrer tes données d'exemple dans Camelis pour obtenir ça :
http://tdegreni.free.fr/temp/test-glis.png
Sur cette image, on est à la racine ("all"). Les 3 incréments proposés sont bien ceux que tu as toi aussi calculés. Quant aux objets listés à droite, ici les 5 y sont (normal, tous les objets sont extension de "all"). Si on rentrait par exemple dans tagA, il ne resterait que les objets 1, 2 et 5. Et le tagC serait proposé comme incrément (il est utile pour rafiner à la navigation, puisqu'il permet d'écarter l'objet 5).

> Ce que je propose c'est de pouvoir naviguer aisément dans ses
> données sans avoir de recherche précise.

C'est exactement le but d'un système comme Camelis. Ce que tu appelles une "recherche précise", c'est le chemin absolu (enfin, un des chemins absolus en fait) d'un certain point de ta hiérarchie. Mais ce point, il est typiquement atteint par naviguation, et ça n'est qu'à chaque nouvelle étape qu'on découvre ce qui pourrait nous faire encore avancer.

Ou bien est-ce le fait que dans beaucoup des exemple qu'on croise dans cette littérature les tags sont valués qui te dérange (genre Artiste="Beatles") ? Si c'est le cas, dit toi juste que tes attributs atomiques ne sont qu'un cas particulier plus simple :)

Enfin bref, le mieux serait peut-être que tu essayes de jouer un peu avec Camelis en fait. Ça permet de palper la chose, et tu pourras toujours en lire plus plus tard...

Je me permet de répondre dans le désordre...

J'ai entandu parler qu'il était possible d'installer des binaires précompilés justement lorsqu'on ne voulait pas faire toutes cos compilations fastidieuses. Cependant, comme gentoo est avant tout une distribution source, je doute qu'il y ait beaucoup de ces paquets précompilés

Il y a une floppées de binaires de genérés pour chaque paquet/archi à chaque nouvelle "release" (j'avais essayé d'expliquer ce qu'est et n'est pas une release sous Gentoo dans l'article de cette dépêche : http://linuxfr.org/2005/03/29/18615.html ). Ça permet d'obtenir une installation rapidement complète et fonctionnelle. Il est à mon avis toujours temps de faire des installations from-sources plus tard, à mesure que des mises à jours sont disponibles ou que des besoins de changer des USE flags se font sentir. Bref, pour moi, faut pas se priver.
Bon par contre, là la dernière release elle date un peu quand même (août 2005 je crois), donc y'a plus grand chose dans les binaires qui ne soit pas à mettre +/- immédiatement à jour.

Alors, est-il possible de faire fonctionner Portage sur Ubuntu ?

Ça, oui. En dehors d'un Bash et d'un Python pas trop vieux, Portage n'a pas des masses de dépendances. Le faire "fonctionner" ne devrait vraiment demander qu'un travail assez mineur.

Ce qui m'intéresse plutôt c'est la facilité d'installation des nouvelles versions des logiciels ... Notament la possibilité de faire un emerge d'un logiciel à partir d'un CVS (ou SVN :) comme par exemple Enlightement 17 ou encore Xgl.

Là par contre, tu vas être déçu. Un Portage qui tourne ça ne veut pas dire des ebuilds qui s'installent correctement. Exactement comme "rpm" est dispo sous Debian/Ubuntu, mais ne permet pas pour autant d'installer n'importe quel paquet Mandriva ou Fedora sans s'exposer à pas mal de soucis... Tu te retrouveras très vite confronté à d'insolubles problèles de dépendances, d'hypothèse non vérifiées sur l'emplacement ou la configuration de trucs divers et variés, des conflits et des écrasements sauvages entre les paquets standards et ceux Gentoo, etc.
Bref, je sens très mal une utilisation des ebuilds tel quel sur une autre distribution. Bien sûr on peut penser à les adapter, mais à mon avis tu vas te retrouver avec autant de boulot que la création de paquets .deb plus propres. Ça reste intéressant par contre de lire ces ebuilds à titre informatif, pour t'en inspirer et choper quelques astuces ou patchs afin de faire tes installations manuelles, ou afin de préparer des vrais paquets dpkg.
Pour e17, ils sont dans l'arbre portage donc tu les as déjà, et pour Xgl c'est par ici: http://dev.gentoo.org/~hanno/

Ton idée d'une hiérarchie minimale qui dépendrait de la répartition effective des tags sur les objets référencés, et donc de leurs éventuelles relations d'«inclusion», est intéressante, mais pas vraiment nouvelle.
Quelques liens passionnants sur le sujet :
http://www.irisa.fr/LIS
ftp://ftp.irisa.fr/techreports/theses/2005/padioleau.pdf
http://www.irisa.fr/lande/ferre/camelis/

Si tu es en Bash en tout cas, tu peux faire ça :

% foo="test@test.com"
% echo ${foo/@/\/}
test/test.com

Et utilises "//" au lieu de "/" si tu veux substituer tous les @ de ta variable dans le cas où il y en aurait plusieurs. Enfin bref, `man bash`, et tu cherches la sous-section "Parameter Expansion", où tu verras plein de choses utiles.

En faible conso et silencieux, y'a quelques NAS personnels près à l'emploi (et sous Linux évidemment) qui peuvent être intéressants.

J'ai lu du bien de ce petit nouveau par exemple (heu, oui, Google Translate est ton ami, tout ça...) :
http://supertank.iodata.jp/products/sotohdlgw/
Il n'est pas bien cher (~180¤ sans disque), est assez puissant (XScale 400MHz et 128Mo de RAM, ce qui permet de s'amuser bien au delà du simple stockage de fichiers), et est apparement assez geek-friendly (console série en option, pas d'entrave majeure contre les changement de distrib', etc.). Reste à voir la disponibilité hors Japon évidemment (geekstuff4u peut-être ?).

Enfin bon, c'est bien sûr juste un exemple que j'ai un peu lorgné ces derniers jours, mais il y en a d'autres dont je n'ai plus les noms en tête.

Et puis sinon, effectivement tu peux fabriquer un truc ~ équivalent sur une base mini-itx. Bon, t'arriveras pas forcement au même niveau de compacité et de consomation, et puis c'est moins geek, mais par contre ça se trouve plus facilement en France, éventuellement même en occasion (enfin, surtout pour les vieilles carte genre l'EPIA 533MHz, qui reste largement suffisante niveau CPU je pense).

Quant à la fiabilité de toutes ces solutions, aucune idée...

Qingy est léger et joli. Il tourne sur le framebuffer, et permet de gérer autant les logins X (via les scripts de session standards) que console (avec là aussi des scripts de session, si ça t'amuse de te logguer direct dans emacs par exemple).
http://qingy.sourceforge.net

> Heu, moi je l'ai vu au cinéma l'année de sa sortie

Pareil.

>> tous les medias ont refuse la diffusion
>
> mauvais médias, changer média ;-)

Pas mieux.

Franchement, ça me saoule de voir le mot CENSURE laché comme ça à tord et à travers à chaque fois qu'un média ne comble pas le moindre de nos petits caprices («TF1 n'as pas diffusé ceci», «DLFP n'a pas publié celà», «Glazblog a fermé ses commentaires», etc.).

> Sinon, si quand tu ouvres ton CD sous windows, si tu vois dessus un
> fichier du genre install-*-2005.1.iso et bien t'a louper ta gravure
> d'image.

Si je comprends bien son message, j'ai plutôt l'impression qu'il a gravé les fichiers contenus dans l'iso, au lieu de la graver directement elle. Enfin Google il me dit que daemontools c'est un truc pour monter des images disque sous windows (un genre de loop quoi, sauf qu'il gère tout plein de bazar de protection cacabeurk), donc j'imagine que c'est ça.

Bref, dadan, ta gravure tu es bon pour la refaire. Dans ton logiciel style Nero ou assimilé, il devrait y avoir une fonction du genre "Graver une image disque", qui te permettra de vraiment transférer à l'identique ton iso sur un CD. C'est ça qu'il faut utiliser, et là il sera bootable bien comme il faut.

<mode_chieur>
Tiens et par contre t'as un bug si il y a des espaces dans le nom de ton processus :P
Faudrait plutôt des $(sed 's:.*) ::' /proc/MACHIN/stat | cut -d' ' -f 20)
</mode_chieur>

Je crois comprendre d'un rapide Google que :
- le HZ du kernel ne se retrouve nulle part dans /proc (des patchs pour l'ajouter sont régulièrement refusés)
- les jiffies qu'on récupère dans /proc sont convertis pour 100Hz de toute façon, même quand le kernel utilise autre chose

D'ailleurs, ici (HZ=1000), ton code marche nickel aussi (avec le "100" inchangé).

Mais peut-être qu'il serait plus prudent d'utiliser quand même $(getconf CLK_TCK) à la place (des fois que sur d'autres archis, ou dans un futur lointain, le «c'est toujours 100» ne soit plus vérifié).

Je sais pas si je dois le dire
Allez si..... , je suis là dessus depuis 4h

Pour ma défense, c'est mon premier script.

Mais c'est très bien de s'acharner 4 heures sur son premier script. ;-)
Y'a vraiment aucune honte, je crois qu'on peut difficilement apprendre les ficelles de Bash sans se casser un peu les dents au début. Enfin perso en tout cas, je n'y avais pas échappé.

Au passage, si jamais y'a des trucs que tu ne comprends pas dans ma solution, et que ça t'intéresse quand même, bah t'hésites pas à demander qlqs explication hein...

Erf, j'ai un bug... Bash il n'aime pas le format "0X" pour un entier... Obligé de faire un truc du genre :

	HH=${BASH_REMATCH[5]#0} ; HH=${HH:-0}
	MM=${BASH_REMATCH[6]#0} ; MM=${MM:-0}
	SS=${BASH_REMATCH[7]#0} ; SS=${SS:-0}

Heu, ouais, nan, sinon une autre solution serait peut-être d'aller chercher ça directement dans /proc/${PID}/stat. Hmmm... ouaif, la flemme de lire `man proc` là...

Attention : ps est aussi susceptible de renvoyer des jours, si temps > 24H :

% ps -p 1 -o etime
    ELAPSED
 1-23:54:12

À part ça, ton idée de parsing ne me choque pas outre mesure. Enfin perso, je l'écrirais comme ça aussi je pense. Genre en Bash-3.x :

#!/bin/bash
PTIME=$(ps -p ${1} -o etime | tail -n 1)
if [[ "$PTIME" =~ "(((([0-9]+)-)?([0-9]+):)?([0-9]+):)?([0-9]+)$" ]] ; then
	DD=${BASH_REMATCH[4]:-0}
	HH=${BASH_REMATCH[5]:-0}
	MM=${BASH_REMATCH[6]:-0}
	SS=${BASH_REMATCH[7]}
	(( TOTAL = (((DD * 24 + HH) * 60 + MM) * 60) + SS  ))
	echo "Elapsed seconds for PID ${1}: ${TOTAL}"
else
	echo "Erreur !" >&2
fi

Test :

% /tmp/ptime 1
Elapsed seconds for PID 1: 172456
% /tmp/ptime 4052
Elapsed seconds for PID 4052: 1292