Je suis en phase de sauvegarde de mes données et puis je me lance. (ma
première gentoo :-).
petite question récurrente : quelle option d'optimisation
utilisez-vous ? la 1,2 ou 3 ?
je me sens d'attaque, je pense que je vais partir du stage 1.
> > Et bien on se contente de copier les binaires la ou ils doivent > aller dans le systeme, mais tu ne t'en rendra meme pas compte si tu > n'y fait pas attention :)
OK, mais c indiqué comment faire ?
emerge lepaquet comme n'importe quel autre :)
> Personnellement je n'utilise pas (a ma connaissance) d'application > propriétaire que ce soit sur mes pc gentoo a la maison ou sur mes > servs gentoo au boulot. ah !!! même pas pour les pilotes spécifiques tels nvidia, ati, intel (centrino), .... ? (ah oui j'oubliais, lecture DVD, real audio/vidéo, ....)
Pour les DVD j'utilise xine je ne crois pas qu'il y ai quoique ce soit de non opensource la dedans. Pour les driver j'utilise ati-drivers en effet bien vu :) Donc pour man laptop c'est vrai j'utilise du proprio :)
Mais attention promit si : http://r300.sourceforge.net/ donne de bon résultats, je switch :)
>> (là je sens que je vais me faire crier dessus !). > > Je te laisserais le soin de te frapper de 100 coups de fouet toi > meme. > >> Cordialement, David. > > Amicalement,
c'est contradictoire avec ta remarque précédente :-).
Mais non c'est pour ton bien :)
Amicalement,
Seb :)
-- mailing list
> > Et bien on se contente de copier les binaires la ou ils doivent
> aller dans le systeme, mais tu ne t'en rendra meme pas compte si tu
> n'y fait pas attention :)
OK, mais c indiqué comment faire ?
emerge lepaquet
comme n'importe quel autre :)
> Personnellement je n'utilise pas (a ma connaissance) d'application
> propriétaire que ce soit sur mes pc gentoo a la maison ou sur mes
> servs gentoo au boulot.
ah !!! même pas pour les pilotes spécifiques tels nvidia, ati, intel
(centrino), .... ? (ah oui j'oubliais, lecture DVD, real audio/vidéo,
....)
Pour les DVD j'utilise xine je ne crois pas qu'il y ai quoique ce soit
de non opensource la dedans.
Pour les driver j'utilise ati-drivers en effet bien vu :)
Donc pour man laptop c'est vrai j'utilise du proprio :)
Mais attention promit si :
http://r300.sourceforge.net/
donne de bon résultats, je switch :)
>> (là je sens que je vais me faire crier dessus !).
>
> Je te laisserais le soin de te frapper de 100 coups de fouet toi
> meme.
>
>> Cordialement, David.
>
> Amicalement,
c'est contradictoire avec ta remarque précédente :-).
> > Et bien on se contente de copier les binaires la ou ils doivent > aller dans le systeme, mais tu ne t'en rendra meme pas compte si tu > n'y fait pas attention :)
OK, mais c indiqué comment faire ?
emerge lepaquet comme n'importe quel autre :)
> Personnellement je n'utilise pas (a ma connaissance) d'application > propriétaire que ce soit sur mes pc gentoo a la maison ou sur mes > servs gentoo au boulot. ah !!! même pas pour les pilotes spécifiques tels nvidia, ati, intel (centrino), .... ? (ah oui j'oubliais, lecture DVD, real audio/vidéo, ....)
Pour les DVD j'utilise xine je ne crois pas qu'il y ai quoique ce soit de non opensource la dedans. Pour les driver j'utilise ati-drivers en effet bien vu :) Donc pour man laptop c'est vrai j'utilise du proprio :)
Mais attention promit si : http://r300.sourceforge.net/ donne de bon résultats, je switch :)
>> (là je sens que je vais me faire crier dessus !). > > Je te laisserais le soin de te frapper de 100 coups de fouet toi > meme. > >> Cordialement, David. > > Amicalement,
c'est contradictoire avec ta remarque précédente :-).
Mais non c'est pour ton bien :)
Amicalement,
Seb :)
-- mailing list
Thomas de Grenier de Latour
On Thu, 31 Mar 2005 15:18:02 +0400 Sebastien Vincent wrote:
> Qu'est-ce qui d'après toi, dans le userland, demanderait une > préparation particulière pour le SMP?
Tous les paquets qui font un : if [ ! -z "`uname -v | grep SMP`" ]
ou encore if [ "${SMP}" = 1 ]; then
Ou alors des trucs genre : # is broken on SMP box
C'est quand même absolument rarissime. En fait, un rapide grep + filtrage a la mano me donne les 4 paquets suivants, où le binaire produit sera différent en cas de système SMP (j'ai viré les cas du style openssl sur Sparc, où le test n'influence pas le résultat mais seulement la façon d'y arriver). Aucun de ces paquet n'est dans le stage3 ou même dans les GRP :
- app-misc/lirc, mais de toute façon c'est un driver, donc à compiler soit même pour qu'il fonctionne avec le noyau qu'on utilise. Par contre je vois un bug d'ebuild puisque la détection du SMP est faite sur le noyau en cours d'exécution, et non sur le noyau cible (/usr/src/linux) comme le reste.
- media-gfx/opendx, qui manifestement possède du code spécial SMP. Là la détection est bien faite par contre, en utilisant /usr/src/linux, et avec possibilité de forcer le truc par une variable d'enironnement.
- x11-plugins/wmsysmon, qui a un USE flag "high-ints" à activer pour qu'il fonctionne correctement sur x86/SMP.
- sys-cluster/mpiexec, où il faut désactiver le partage de mémoire pour MPICH/P4. (Et là encore la détection est pourrie d'ailleurs).
-- TGL.
-- mailing list
On Thu, 31 Mar 2005 15:18:02 +0400
Sebastien Vincent <svincent@idems.fr> wrote:
> Qu'est-ce qui d'après toi, dans le userland, demanderait une
> préparation particulière pour le SMP?
Tous les paquets qui font un :
if [ ! -z "`uname -v | grep SMP`" ]
ou encore
if [ "${SMP}" = 1 ]; then
Ou alors des trucs genre :
# is broken on SMP box
C'est quand même absolument rarissime. En fait, un rapide grep +
filtrage a la mano me donne les 4 paquets suivants, où le binaire
produit sera différent en cas de système SMP (j'ai viré les cas
du style openssl sur Sparc, où le test n'influence pas le résultat
mais seulement la façon d'y arriver). Aucun de ces paquet n'est
dans le stage3 ou même dans les GRP :
- app-misc/lirc, mais de toute façon c'est un driver, donc à
compiler soit même pour qu'il fonctionne avec le noyau qu'on
utilise. Par contre je vois un bug d'ebuild puisque la détection
du SMP est faite sur le noyau en cours d'exécution, et non sur le
noyau cible (/usr/src/linux) comme le reste.
- media-gfx/opendx, qui manifestement possède du code spécial
SMP. Là la détection est bien faite par contre, en utilisant
/usr/src/linux, et avec possibilité de forcer le truc par une
variable d'enironnement.
- x11-plugins/wmsysmon, qui a un USE flag "high-ints" à activer
pour qu'il fonctionne correctement sur x86/SMP.
- sys-cluster/mpiexec, où il faut désactiver le partage de
mémoire pour MPICH/P4. (Et là encore la détection est pourrie
d'ailleurs).
On Thu, 31 Mar 2005 15:18:02 +0400 Sebastien Vincent wrote:
> Qu'est-ce qui d'après toi, dans le userland, demanderait une > préparation particulière pour le SMP?
Tous les paquets qui font un : if [ ! -z "`uname -v | grep SMP`" ]
ou encore if [ "${SMP}" = 1 ]; then
Ou alors des trucs genre : # is broken on SMP box
C'est quand même absolument rarissime. En fait, un rapide grep + filtrage a la mano me donne les 4 paquets suivants, où le binaire produit sera différent en cas de système SMP (j'ai viré les cas du style openssl sur Sparc, où le test n'influence pas le résultat mais seulement la façon d'y arriver). Aucun de ces paquet n'est dans le stage3 ou même dans les GRP :
- app-misc/lirc, mais de toute façon c'est un driver, donc à compiler soit même pour qu'il fonctionne avec le noyau qu'on utilise. Par contre je vois un bug d'ebuild puisque la détection du SMP est faite sur le noyau en cours d'exécution, et non sur le noyau cible (/usr/src/linux) comme le reste.
- media-gfx/opendx, qui manifestement possède du code spécial SMP. Là la détection est bien faite par contre, en utilisant /usr/src/linux, et avec possibilité de forcer le truc par une variable d'enironnement.
- x11-plugins/wmsysmon, qui a un USE flag "high-ints" à activer pour qu'il fonctionne correctement sur x86/SMP.
- sys-cluster/mpiexec, où il faut désactiver le partage de mémoire pour MPICH/P4. (Et là encore la détection est pourrie d'ailleurs).
-- TGL.
-- mailing list
Sebastien Vincent
> C'est quand même absolument rarissime. En fait, un rapide grep + filtrage a la mano me donne les 4 paquets suivants, où le binaire produit sera différent en cas de système SMP (j'ai viré les cas du style openssl sur Sparc, où le test n'influence pas le résultat mais seulement la façon d'y arriver). Aucun de ces paquet n'est dans le stage3 ou même dans les GRP :
Donc on peux dire que le noyau smp du livecd ne sert qu'a aller plus vite à la compilation ?
Et que le stage3 est parfaitement adaptés aux smp ?
- app-misc/lirc, mais de toute façon c'est un driver, donc à compiler soit même pour qu'il fonctionne avec le noyau qu'on utilise. Par contre je vois un bug d'ebuild puisque la détection du SMP est faite sur le noyau en cours d'exécution, et non sur le noyau cible (/usr/src/linux) comme le reste.
Pour le bug préviens le maintener si ce n'est déja fait :)
Amicalement,
seb :)
-- mailing list
> C'est quand même absolument rarissime. En fait, un rapide grep +
filtrage a la mano me donne les 4 paquets suivants, où le binaire
produit sera différent en cas de système SMP (j'ai viré les cas du
style openssl sur Sparc, où le test n'influence pas le résultat mais
seulement la façon d'y arriver). Aucun de ces paquet n'est dans le
stage3 ou même dans les GRP :
Donc on peux dire que le noyau smp du livecd ne sert qu'a aller plus
vite à la compilation ?
Et que le stage3 est parfaitement adaptés aux smp ?
- app-misc/lirc, mais de toute façon c'est un driver, donc à compiler
soit même pour qu'il fonctionne avec le noyau qu'on utilise. Par
contre je vois un bug d'ebuild puisque la détection du SMP est faite
sur le noyau en cours d'exécution, et non sur le noyau cible
(/usr/src/linux) comme le reste.
Pour le bug préviens le maintener si ce n'est déja fait :)
> C'est quand même absolument rarissime. En fait, un rapide grep + filtrage a la mano me donne les 4 paquets suivants, où le binaire produit sera différent en cas de système SMP (j'ai viré les cas du style openssl sur Sparc, où le test n'influence pas le résultat mais seulement la façon d'y arriver). Aucun de ces paquet n'est dans le stage3 ou même dans les GRP :
Donc on peux dire que le noyau smp du livecd ne sert qu'a aller plus vite à la compilation ?
Et que le stage3 est parfaitement adaptés aux smp ?
- app-misc/lirc, mais de toute façon c'est un driver, donc à compiler soit même pour qu'il fonctionne avec le noyau qu'on utilise. Par contre je vois un bug d'ebuild puisque la détection du SMP est faite sur le noyau en cours d'exécution, et non sur le noyau cible (/usr/src/linux) comme le reste.
Pour le bug préviens le maintener si ce n'est déja fait :)
Amicalement,
seb :)
-- mailing list
Thomas de Grenier de Latour
On Thu, 31 Mar 2005 17:30:18 +0400 Sebastien Vincent wrote:
Donc on peux dire que le noyau smp du livecd ne sert qu'a aller plus vite à la compilation ?
Je dirais oui. Et peut-être aussi que certaines machines multi-pro n'aiment pas les noyaux mono-pro, mais alors là c'est complètement hypothétique.
Et que le stage3 est parfaitement adaptés aux smp ?
Je dirais oui aussi.
Pour le bug préviens le maintener si ce n'est déja fait :)
Yep, bien sûr. ... Voilà: bug #87412 :)
-- TGL.
-- mailing list
On Thu, 31 Mar 2005 17:30:18 +0400
Sebastien Vincent <svincent@idems.fr> wrote:
Donc on peux dire que le noyau smp du livecd ne sert qu'a aller
plus vite à la compilation ?
Je dirais oui. Et peut-être aussi que certaines machines multi-pro
n'aiment pas les noyaux mono-pro, mais alors là c'est complètement
hypothétique.
Et que le stage3 est parfaitement adaptés aux smp ?
Je dirais oui aussi.
Pour le bug préviens le maintener si ce n'est déja fait :)
On Thu, 31 Mar 2005 17:30:18 +0400 Sebastien Vincent wrote:
Donc on peux dire que le noyau smp du livecd ne sert qu'a aller plus vite à la compilation ?
Je dirais oui. Et peut-être aussi que certaines machines multi-pro n'aiment pas les noyaux mono-pro, mais alors là c'est complètement hypothétique.
Et que le stage3 est parfaitement adaptés aux smp ?
Je dirais oui aussi.
Pour le bug préviens le maintener si ce n'est déja fait :)
Yep, bien sûr. ... Voilà: bug #87412 :)
-- TGL.
-- mailing list
Sebastien Vincent
> > Donc on peux dire que le noyau smp du livecd ne sert qu'a aller > plus vite à la compilation ? Je dirais oui. Et peut-être aussi que certaines machines multi-pro n'aiment pas les noyaux mono-pro, mais alors là c'est complètement hypothétique.
Une fois j'ai du booter le noyau smp sur un single processor car le 2.4 plantait. c'était 2004.0 je crois.
J'ai mis MAKEOPTS="-J1" Cela servait-til a quelque chose ?
Ensuite j'ai le bootstrap et le systeme, puis j'ai compilé mon noyau sans smp, puis j'ai rebooté puis j'ai recompilé gcc puis j'ai recompilé tout le systeme. C'était le bonne méthode ?
> Et que le stage3 est parfaitement adaptés aux smp ? Je dirais oui aussi.
ok :)
> Pour le bug préviens le maintener si ce n'est déja fait :) Yep, bien sûr. ... Voilà: bug #87412 :)
un de plus :)
Si j'avais du temps j'essairais d'en corriger quelques uns a ma portée, mais j'ai trop de choses a faire deja :)
Amicalement,
Seb :)
-- mailing list
> > Donc on peux dire que le noyau smp du livecd ne sert qu'a aller
> plus vite à la compilation ?
Je dirais oui. Et peut-être aussi que certaines machines multi-pro
n'aiment pas les noyaux mono-pro, mais alors là c'est complètement
hypothétique.
Une fois j'ai du booter le noyau smp sur un single processor car le 2.4
plantait.
c'était 2004.0 je crois.
J'ai mis MAKEOPTS="-J1" Cela servait-til a quelque chose ?
Ensuite j'ai le bootstrap et le systeme, puis j'ai compilé mon noyau
sans smp, puis
j'ai rebooté puis j'ai recompilé gcc puis j'ai recompilé tout le
systeme. C'était le bonne
méthode ?
> Et que le stage3 est parfaitement adaptés aux smp ?
Je dirais oui aussi.
ok :)
> Pour le bug préviens le maintener si ce n'est déja fait :)
Yep, bien sûr. ... Voilà: bug #87412 :)
un de plus :)
Si j'avais du temps j'essairais d'en corriger quelques uns a ma portée,
mais j'ai
trop de choses a faire deja :)
> > Donc on peux dire que le noyau smp du livecd ne sert qu'a aller > plus vite à la compilation ? Je dirais oui. Et peut-être aussi que certaines machines multi-pro n'aiment pas les noyaux mono-pro, mais alors là c'est complètement hypothétique.
Une fois j'ai du booter le noyau smp sur un single processor car le 2.4 plantait. c'était 2004.0 je crois.
J'ai mis MAKEOPTS="-J1" Cela servait-til a quelque chose ?
Ensuite j'ai le bootstrap et le systeme, puis j'ai compilé mon noyau sans smp, puis j'ai rebooté puis j'ai recompilé gcc puis j'ai recompilé tout le systeme. C'était le bonne méthode ?
> Et que le stage3 est parfaitement adaptés aux smp ? Je dirais oui aussi.
ok :)
> Pour le bug préviens le maintener si ce n'est déja fait :) Yep, bien sûr. ... Voilà: bug #87412 :)
un de plus :)
Si j'avais du temps j'essairais d'en corriger quelques uns a ma portée, mais j'ai trop de choses a faire deja :)
