au debut aucun probleme avec la gentoo mais maintenant c'est souvent ca:
/usr/lib/libGL.so: undefined reference to `_nv000793gl'
/usr/lib/libGL.so: undefined reference to `_nv000795gl'
/usr/lib/libGL.so: undefined reference to `_nv000792gl'
/usr/lib/libGL.so: undefined reference to `_nv000797gl'
/usr/lib/libGL.so: undefined reference to `_nv000794gl'
/usr/lib/libGL.so: undefined reference to `_nv000800gl'
/usr/lib/libGL.so: undefined reference to `_nv000798gl'
/usr/lib/libGLcore.so.1: undefined reference to `_nv000790gl'
/usr/lib/libGL.so: undefined reference to `_nv000796gl'
/usr/lib/libGL.so: undefined reference to `_nv000791gl'
/usr/lib/libGL.so: undefined reference to `_nv000799gl'
/usr/lib/libGL.so: undefined reference to `_nv000801gl'
collect2: ld returned 1 exit status
make[1]: *** [glmovie] Error 1
make[1]: Leaving directory
`/var/tmp/portage/smpeg-0.4.4-r5/work/smpeg-0.4.4'
make: *** [all-recursive] Error 1
!!! ERROR: media-libs/smpeg-0.4.4-r5 failed.
!!! Function src_compile, Line 47, Exitcode 2
!!! emake failed
!!! If you need support, post the topmost build error, NOT this status
message.
On Sat, 02 Apr 2005 22:04:33 +0200, Jerome Lambert wrote:
l'indien wrote:
On Sat, 02 Apr 2005 20:36:30 +0200, yvnico wrote:
none wrote:
au debut aucun probleme avec la gentoo mais maintenant c'est souvent ca:
<troll> T'as pas choisi la distrib la plus simple non plus. </troll>
C'est de la diffamation ! En quoi est-elle compliquée ?
Qu'elle est plus compliquée que de booter sur le CD, faire "Suivant" autant de fois que nécessaire et puis rebooter sur la distribution fraichement installée?
Bah non, tu bootes, tu as un shell et tu lances: /usr/portage/scripts/bootstrap.sh && emerge system && emerge sync Tu édites ta config (/etc/make.conf) puis emerge --deep --update system et tu as un système utilisable (enfin, manque le noyau...). Qu'y-a-t-il de compliqué par rapport à répondre 100 fois à la même question (Debian) ou essayer 10 fois parce que le partitionnement automatique fait n'importe quoi (Mandrake) voire que la distrib fraichement installée crash au reboot (vu pour la dernière fois avec une Fedora)...
Le seul défaut qu'on peut objectivement (parce que c'est bien beau le mode troll, mais bon, faut être un peu sérieux ;-) lui reprocher, c'est que sur cette machine, c'est dès fois un peu lent à installer:
=> PowerPC 405 sans FPU avec le cache de la MMU (les TLB) gérés en soft.
il faut à peu près une semaine pour compiler gcc, pour donner un ordre de grandeur... Une semaine pour compiler gcc?je suis mort ecroulé par terre de rire:)
l'indien wrote:
On Sat, 02 Apr 2005 22:04:33 +0200, Jerome Lambert wrote:
l'indien wrote:
On Sat, 02 Apr 2005 20:36:30 +0200, yvnico wrote:
none wrote:
au debut aucun probleme avec la gentoo mais maintenant c'est souvent ca:
<troll>
T'as pas choisi la distrib la plus simple non plus.
</troll>
C'est de la diffamation !
En quoi est-elle compliquée ?
Qu'elle est plus compliquée que de booter sur le CD, faire "Suivant"
autant de fois que nécessaire et puis rebooter sur la distribution
fraichement installée?
Bah non, tu bootes, tu as un shell et tu lances:
/usr/portage/scripts/bootstrap.sh && emerge system && emerge sync
Tu édites ta config (/etc/make.conf) puis
emerge --deep --update system
et tu as un système utilisable (enfin, manque le noyau...).
Qu'y-a-t-il de compliqué par rapport à répondre 100 fois à la même
question (Debian) ou essayer 10 fois parce que le partitionnement
automatique fait n'importe quoi (Mandrake) voire que la distrib
fraichement installée crash au reboot (vu pour la dernière fois avec une
Fedora)...
Le seul défaut qu'on peut objectivement (parce que c'est bien beau le
mode troll, mais bon, faut être un peu sérieux ;-) lui reprocher, c'est
que sur cette machine, c'est dès fois un peu lent à installer:
=> PowerPC 405 sans FPU avec le cache de la MMU (les TLB) gérés en soft.
il faut à peu près une semaine pour compiler gcc, pour donner un ordre
de grandeur...
Une semaine pour compiler gcc?je suis mort ecroulé par terre de rire:)
On Sat, 02 Apr 2005 22:04:33 +0200, Jerome Lambert wrote:
l'indien wrote:
On Sat, 02 Apr 2005 20:36:30 +0200, yvnico wrote:
none wrote:
au debut aucun probleme avec la gentoo mais maintenant c'est souvent ca:
<troll> T'as pas choisi la distrib la plus simple non plus. </troll>
C'est de la diffamation ! En quoi est-elle compliquée ?
Qu'elle est plus compliquée que de booter sur le CD, faire "Suivant" autant de fois que nécessaire et puis rebooter sur la distribution fraichement installée?
Bah non, tu bootes, tu as un shell et tu lances: /usr/portage/scripts/bootstrap.sh && emerge system && emerge sync Tu édites ta config (/etc/make.conf) puis emerge --deep --update system et tu as un système utilisable (enfin, manque le noyau...). Qu'y-a-t-il de compliqué par rapport à répondre 100 fois à la même question (Debian) ou essayer 10 fois parce que le partitionnement automatique fait n'importe quoi (Mandrake) voire que la distrib fraichement installée crash au reboot (vu pour la dernière fois avec une Fedora)...
Le seul défaut qu'on peut objectivement (parce que c'est bien beau le mode troll, mais bon, faut être un peu sérieux ;-) lui reprocher, c'est que sur cette machine, c'est dès fois un peu lent à installer:
=> PowerPC 405 sans FPU avec le cache de la MMU (les TLB) gérés en soft.
il faut à peu près une semaine pour compiler gcc, pour donner un ordre de grandeur... Une semaine pour compiler gcc?je suis mort ecroulé par terre de rire:)
du64
Michel Talon wrote:
Jerome Lambert wrote:
Bah, chez moi sur un P-3 450 ça n'a pas duré trop longtemps (plus quand même que sur mon Athlon64 3000+), mais quel plaisir d'y arriver ;-)
Prochaine étape: acheter un disque externe FireWire pour mon iMac G5 et y installer une Gentoo PPC, mais ce sera "quand j'aurai le temps"...
Sincèrement je ne connais pas la Gentoo ni si son administration est facile, mais je n'arrive pas à comprendre pourquoi vous vous escrimez à recompiler le système. Ils doivent bien fournir un système pré-compilé quand même, sur lequel on peut tourner "faute de mieux". Je te mets au défi de prouver chiffres à l'appui que l'OS ira "plus vite" si tu le compiles mieux, avec de meilleurs optimisations plus adaptées à la machine. Moi qui fais du calcul scientifique, je peux t'assurer qu'il y a de nombreux programmes qui tournent plus vite compilés avec -O que avec -O2 ou -O3. C'est programme par programme qu'il faut choisir les options de compilation. De toute façon sur un OS où la quasi totalité du temps se passe à converser avec des périphériques, toute différence de temps liée au choix des instructions processeur n'est pas mesurable. L'un des rares codes de l'OS qu'il faut soigner c'est le code qui fournit des blocs remplis de zéros, et en général ce code est écrit en assembleur et utilise directement les instructions adaptées à la machine. Par contre recompiler mplayer pour l'optimiser, évidemment d'accord. Si FreeBSD pousse à recompiler le système pour les upgrades, c'est pour des raisons de commodité, parceque c'est trés facile d'upgrader comme ça, et que ça prend de 1/2 heure à 1 heure selon la machine, mais certainement pas pour des raisons de performance.
copier/coller:)
si GNU/Linux pousse à recompiler le système pour les upgrades, c'est pour des raisons de commodité, parceque c'est trés facile d'upgrader comme ça, et que ça prend de 1/2 heure à 1 heure selon la machine, mais certainement pas pour des raisons de performance.
Michel Talon wrote:
Jerome Lambert <jerome.lambert@swing.be> wrote:
Bah, chez moi sur un P-3 450 ça n'a pas duré trop longtemps (plus quand
même que sur mon Athlon64 3000+), mais quel plaisir d'y arriver ;-)
Prochaine étape: acheter un disque externe FireWire pour mon iMac G5 et
y installer une Gentoo PPC, mais ce sera "quand j'aurai le temps"...
Sincèrement je ne connais pas la Gentoo ni si son administration est facile,
mais je n'arrive pas à comprendre pourquoi vous vous escrimez à recompiler
le système. Ils doivent bien fournir un système pré-compilé quand même,
sur lequel on peut tourner "faute de mieux". Je te mets au défi de prouver
chiffres à l'appui que l'OS ira "plus vite" si tu le compiles mieux, avec
de meilleurs optimisations plus adaptées à la machine. Moi qui fais du calcul
scientifique, je peux t'assurer qu'il y a de nombreux programmes qui tournent
plus vite compilés avec -O que avec -O2 ou -O3. C'est programme par programme
qu'il faut choisir les options de compilation. De toute façon sur un OS où
la quasi totalité du temps se passe à converser avec des périphériques, toute
différence de temps liée au choix des instructions processeur n'est pas
mesurable. L'un des rares codes de l'OS qu'il faut soigner c'est le code qui
fournit des blocs remplis de zéros, et en général ce code est écrit en
assembleur et utilise directement les instructions adaptées à la machine.
Par contre recompiler mplayer pour l'optimiser, évidemment d'accord.
Si FreeBSD pousse à recompiler le système pour les upgrades, c'est pour des
raisons de commodité, parceque c'est trés facile d'upgrader comme ça, et
que ça prend de 1/2 heure à 1 heure selon la machine, mais certainement pas
pour des raisons de performance.
copier/coller:)
si GNU/Linux pousse à recompiler le système pour les upgrades, c'est
pour des
raisons de commodité, parceque c'est trés facile d'upgrader comme ça, et
que ça prend de 1/2 heure à 1 heure selon la machine, mais certainement pas
pour des raisons de performance.
Bah, chez moi sur un P-3 450 ça n'a pas duré trop longtemps (plus quand même que sur mon Athlon64 3000+), mais quel plaisir d'y arriver ;-)
Prochaine étape: acheter un disque externe FireWire pour mon iMac G5 et y installer une Gentoo PPC, mais ce sera "quand j'aurai le temps"...
Sincèrement je ne connais pas la Gentoo ni si son administration est facile, mais je n'arrive pas à comprendre pourquoi vous vous escrimez à recompiler le système. Ils doivent bien fournir un système pré-compilé quand même, sur lequel on peut tourner "faute de mieux". Je te mets au défi de prouver chiffres à l'appui que l'OS ira "plus vite" si tu le compiles mieux, avec de meilleurs optimisations plus adaptées à la machine. Moi qui fais du calcul scientifique, je peux t'assurer qu'il y a de nombreux programmes qui tournent plus vite compilés avec -O que avec -O2 ou -O3. C'est programme par programme qu'il faut choisir les options de compilation. De toute façon sur un OS où la quasi totalité du temps se passe à converser avec des périphériques, toute différence de temps liée au choix des instructions processeur n'est pas mesurable. L'un des rares codes de l'OS qu'il faut soigner c'est le code qui fournit des blocs remplis de zéros, et en général ce code est écrit en assembleur et utilise directement les instructions adaptées à la machine. Par contre recompiler mplayer pour l'optimiser, évidemment d'accord. Si FreeBSD pousse à recompiler le système pour les upgrades, c'est pour des raisons de commodité, parceque c'est trés facile d'upgrader comme ça, et que ça prend de 1/2 heure à 1 heure selon la machine, mais certainement pas pour des raisons de performance.
copier/coller:)
si GNU/Linux pousse à recompiler le système pour les upgrades, c'est pour des raisons de commodité, parceque c'est trés facile d'upgrader comme ça, et que ça prend de 1/2 heure à 1 heure selon la machine, mais certainement pas pour des raisons de performance.
VAQUIN Vincent
Par expérience, je doute qu'une RedHat ou une mandrake puisse tenir longtemps à ce petit jeu (mi-RPM, mi-source)
Et si on fait des rpm à partir des sources ?
Par expérience, je doute qu'une RedHat ou une mandrake puisse tenir
longtemps à ce petit jeu (mi-RPM, mi-source)
Par expérience, je doute qu'une RedHat ou une mandrake puisse tenir longtemps à ce petit jeu (mi-RPM, mi-source)
Et si on fait des rpm à partir des sources ?
du64
Doug713705 wrote:
Le Dimanche 3 Avril 2005 04:49, Boogabi s'est exprimé de la sorte sur fr.comp.os.linux.debats :
L'essayer, c'est l'adopter ;)
J'aurais bien voulu en dire autant (j'ai fais plusieurs tentatives) mais malgré la lecture attentive de la doc et après plusieurs jours de compilation, un nombre conséquent de problèmes de dépendance (!) notament avec Perl j'ai fini par réinstaller Slackware en me disant (à tort ou à raison) que Gentoo n'était pas encore mûre.
Mais je rééssaierai (je suis tétu ;-)) car la philiophie de cette distrib est exactement ce que je recherche.
En attendant et depuis plusieurs années, Slackware m'apporte une grande satifaction et une très bonne stabilité malgré un système partiellement mis à jour par swaret et partiellement à partir des sources (je parle de la méthode "configure, make, make install" à l'ancienne)
Par expérience, je doute qu'une RedHat ou une mandrake puisse tenir longtemps à ce petit jeu (mi-RPM, mi-source)
J'utilise gentoo depuis un moment malgré que le premier linux que j'ai
connu c'etais slackware,j'ai toujours une slackware installé mais bon c'est un kernel 2.4 et ya moins le choix de logiciels comparé a une gentoo.Bien sur dans toutes les distributions ya tous les logiciels mais il faut aller les cherchés parce que c'est pas libre ou pour une autre raison,avec le system de portage de gentoo ya tout meme les jeux commerciaux.Par example ya le jeux nwn + le pack communautaire CEP dans le portage...
Doug713705 wrote:
Le Dimanche 3 Avril 2005 04:49, Boogabi s'est exprimé de la sorte sur
fr.comp.os.linux.debats :
L'essayer, c'est l'adopter ;)
J'aurais bien voulu en dire autant (j'ai fais plusieurs tentatives) mais
malgré la lecture attentive de la doc et après plusieurs jours de
compilation, un nombre conséquent de problèmes de dépendance (!) notament
avec Perl j'ai fini par réinstaller Slackware en me disant (à tort ou à
raison) que Gentoo n'était pas encore mûre.
Mais je rééssaierai (je suis tétu ;-)) car la philiophie de cette distrib
est exactement ce que je recherche.
En attendant et depuis plusieurs années, Slackware m'apporte une grande
satifaction et une très bonne stabilité malgré un système partiellement mis
à jour par swaret et partiellement à partir des sources (je parle de la
méthode "configure, make, make install" à l'ancienne)
Par expérience, je doute qu'une RedHat ou une mandrake puisse tenir
longtemps à ce petit jeu (mi-RPM, mi-source)
J'utilise gentoo depuis un moment malgré que le premier linux que j'ai
connu c'etais slackware,j'ai toujours une slackware installé mais bon
c'est un kernel 2.4 et ya moins le choix de logiciels comparé a une
gentoo.Bien sur dans toutes les distributions ya tous les logiciels mais
il faut aller les cherchés parce que c'est pas libre ou pour une autre
raison,avec le system de portage de gentoo ya tout meme les jeux
commerciaux.Par example ya le jeux nwn + le pack communautaire CEP dans
le portage...
Le Dimanche 3 Avril 2005 04:49, Boogabi s'est exprimé de la sorte sur fr.comp.os.linux.debats :
L'essayer, c'est l'adopter ;)
J'aurais bien voulu en dire autant (j'ai fais plusieurs tentatives) mais malgré la lecture attentive de la doc et après plusieurs jours de compilation, un nombre conséquent de problèmes de dépendance (!) notament avec Perl j'ai fini par réinstaller Slackware en me disant (à tort ou à raison) que Gentoo n'était pas encore mûre.
Mais je rééssaierai (je suis tétu ;-)) car la philiophie de cette distrib est exactement ce que je recherche.
En attendant et depuis plusieurs années, Slackware m'apporte une grande satifaction et une très bonne stabilité malgré un système partiellement mis à jour par swaret et partiellement à partir des sources (je parle de la méthode "configure, make, make install" à l'ancienne)
Par expérience, je doute qu'une RedHat ou une mandrake puisse tenir longtemps à ce petit jeu (mi-RPM, mi-source)
J'utilise gentoo depuis un moment malgré que le premier linux que j'ai
connu c'etais slackware,j'ai toujours une slackware installé mais bon c'est un kernel 2.4 et ya moins le choix de logiciels comparé a une gentoo.Bien sur dans toutes les distributions ya tous les logiciels mais il faut aller les cherchés parce que c'est pas libre ou pour une autre raison,avec le system de portage de gentoo ya tout meme les jeux commerciaux.Par example ya le jeux nwn + le pack communautaire CEP dans le portage...
l'indien
On Sun, 03 Apr 2005 08:15:13 +0000, Michel Talon wrote:
l'indien wrote:
qu'il faut choisir les options de compilation. De toute façon sur un OS où ^^^^^
la quasi totalité du temps se passe à converser avec des périphériques,
Si ton OS passe la majorité de son temps en attente d'I/O, soit tu travailles uniquement avec des disques réseaux, soit tu as un gros problème matériel. Le temps passé en attente d'I/O dépasse rarement les 10% du temps CPU.
Je n'ai pas parlé de programme qui passe tout son temps en attente d'IO, j'ai parlé spécifiquement de l'OS qui lui passe certainement la plus grande partie de son temps à gérer de l'IO. Evidemment que les programmes en userland passent leur temps à utiliser le CPU.
OK, j'ai donc mal compris ce que tu voulais dire.
Et bien, tu pourrais au moins garder cet argument pourla gentoo, non ? Et puis, si tu n'est pas convaincu, fait l'essai: compile 2 Gentoo, l'une entièrement en -O, l'autre avec des optimisations correctes et compare ensuite le temps de boot, la consomation mémoire, etc..., tu risque d'avoir quelques surprises, je pense.
Non plutôt toi, quand tu découvriras que ça ne change absolument rien. Je parle du kernel, pas d'applications gourmandes en calcul comme mplayer, évidemment.
Oui, mais comme en général on passe très peu de temps dans le noyau, optimiser les fonctions non critique du noyau n'a effectivement pas beaucoup d'intérêt. Ce qui doit être optimisé, ce sont les switch de contexte et la gestion des interruptions, par ex. A par celà, le reste est beaucoup moins critique, en effet. Par contre, la majorité du temps CPU consomé l'étant en mode user, c'est bien là qu'il faut se concentrer si on veut optimiser un système complet. C'est bien ce que je voulais souligner.
Le temps de boot est certainement un exemple caricatural car le temps est passé à faire des probes sur le hardware, donc ça risque peu de dépendre des optimisations de compilation.
Le temps du probe du hardware est assez court (quelques secondes au maximum). Le seul contre exemple que je connaisse, c'est le probe SCSI qui demande d'attendre jusqu'à ~10 secondes par disque, le temps que ceux-ci démare. Sur mes machines non SCSI, le temps de boot du noyau est négligeable (moins de 5 secondes). Mais c'est vrai qu'il n'est pas facilement réductible: je ne vois guère de différence entre une machine à 100 Mhz et une à 3 Ghz, à équipement équivalent, à ce niveau. Une fois qu'on est en mode user, par contre, tout change (à part le temps de chargement et d'initialisation des modules qui est également difficilement optimisable).
Par contre si tu passes ton temps à lancer des myriades de shell scripts au démarrage des services, et compilés en dynamique pour faire bonne mesure, comme sur les RedHat, Mandrake, etc, il ne faut pas s'étonner de ce que ça prenne des plombes.
Je ne voulais même pas parler de ce genre d'horreurs. Je parle juste du temps de lancement et d'initialisation des services en eux mêmes. Si le code est mal optimisé, il sera généralement plus gros, donc mettra à la fois plus de temps à se charger _et_ à s'executer et consomera plus de mémoire. C'est la raison pour laquelle c'est plus visible pour le boot que lors du fonctionnement nominal de la machine.
On Sun, 03 Apr 2005 08:15:13 +0000, Michel Talon wrote:
l'indien <l_indien_no_more_spams@magic.fr> wrote:
qu'il faut choisir les options de compilation. De toute façon sur un OS où
^^^^^
la quasi totalité du temps se passe à converser avec des périphériques,
Si ton OS passe la majorité de son temps en attente d'I/O, soit tu
travailles uniquement avec des disques réseaux, soit tu as un gros
problème matériel. Le temps passé en attente d'I/O dépasse rarement
les 10% du temps CPU.
Je n'ai pas parlé de programme qui passe tout son temps en attente d'IO,
j'ai parlé spécifiquement de l'OS qui lui passe certainement la plus grande
partie de son temps à gérer de l'IO. Evidemment que les programmes en userland
passent leur temps à utiliser le CPU.
OK, j'ai donc mal compris ce que tu voulais dire.
Et bien, tu pourrais au moins garder cet argument pourla gentoo, non ?
Et puis, si tu n'est pas convaincu, fait l'essai: compile 2 Gentoo, l'une
entièrement en -O, l'autre avec des optimisations correctes et compare
ensuite le temps de boot, la consomation mémoire, etc..., tu risque
d'avoir quelques surprises, je pense.
Non plutôt toi, quand tu découvriras que ça ne change absolument rien. Je
parle du kernel, pas d'applications gourmandes en calcul comme mplayer,
évidemment.
Oui, mais comme en général on passe très peu de temps dans le noyau,
optimiser les fonctions non critique du noyau n'a effectivement pas
beaucoup d'intérêt. Ce qui doit être optimisé, ce sont les switch de
contexte et la gestion des interruptions, par ex. A par celà, le reste
est beaucoup moins critique, en effet.
Par contre, la majorité du temps CPU consomé l'étant en mode user,
c'est bien là qu'il faut se concentrer si on veut optimiser un système
complet. C'est bien ce que je voulais souligner.
Le temps de boot est certainement un exemple caricatural car
le temps est passé à faire des probes sur le hardware, donc ça risque peu
de dépendre des optimisations de compilation.
Le temps du probe du hardware est assez court (quelques secondes au
maximum). Le seul contre exemple que je connaisse, c'est le probe SCSI qui
demande d'attendre jusqu'à ~10 secondes par disque, le temps que ceux-ci
démare. Sur mes machines non SCSI, le temps de boot du noyau est
négligeable (moins de 5 secondes). Mais c'est vrai qu'il n'est
pas facilement réductible: je ne vois guère de différence entre une
machine à 100 Mhz et une à 3 Ghz, à équipement équivalent, à ce niveau.
Une fois qu'on est en mode user, par contre, tout change (à part le temps
de chargement et d'initialisation des modules qui est également
difficilement optimisable).
Par contre si tu passes
ton temps à lancer des myriades de shell scripts au démarrage des services,
et compilés en dynamique pour faire bonne mesure, comme sur les RedHat,
Mandrake, etc, il ne faut pas s'étonner de ce que ça prenne des plombes.
Je ne voulais même pas parler de ce genre d'horreurs. Je parle juste du
temps de lancement et d'initialisation des services en eux mêmes.
Si le code est mal optimisé, il sera généralement plus gros, donc
mettra à la fois plus de temps à se charger _et_ à s'executer et
consomera plus de mémoire. C'est la raison pour laquelle c'est plus
visible pour le boot que lors du fonctionnement nominal de la machine.
On Sun, 03 Apr 2005 08:15:13 +0000, Michel Talon wrote:
l'indien wrote:
qu'il faut choisir les options de compilation. De toute façon sur un OS où ^^^^^
la quasi totalité du temps se passe à converser avec des périphériques,
Si ton OS passe la majorité de son temps en attente d'I/O, soit tu travailles uniquement avec des disques réseaux, soit tu as un gros problème matériel. Le temps passé en attente d'I/O dépasse rarement les 10% du temps CPU.
Je n'ai pas parlé de programme qui passe tout son temps en attente d'IO, j'ai parlé spécifiquement de l'OS qui lui passe certainement la plus grande partie de son temps à gérer de l'IO. Evidemment que les programmes en userland passent leur temps à utiliser le CPU.
OK, j'ai donc mal compris ce que tu voulais dire.
Et bien, tu pourrais au moins garder cet argument pourla gentoo, non ? Et puis, si tu n'est pas convaincu, fait l'essai: compile 2 Gentoo, l'une entièrement en -O, l'autre avec des optimisations correctes et compare ensuite le temps de boot, la consomation mémoire, etc..., tu risque d'avoir quelques surprises, je pense.
Non plutôt toi, quand tu découvriras que ça ne change absolument rien. Je parle du kernel, pas d'applications gourmandes en calcul comme mplayer, évidemment.
Oui, mais comme en général on passe très peu de temps dans le noyau, optimiser les fonctions non critique du noyau n'a effectivement pas beaucoup d'intérêt. Ce qui doit être optimisé, ce sont les switch de contexte et la gestion des interruptions, par ex. A par celà, le reste est beaucoup moins critique, en effet. Par contre, la majorité du temps CPU consomé l'étant en mode user, c'est bien là qu'il faut se concentrer si on veut optimiser un système complet. C'est bien ce que je voulais souligner.
Le temps de boot est certainement un exemple caricatural car le temps est passé à faire des probes sur le hardware, donc ça risque peu de dépendre des optimisations de compilation.
Le temps du probe du hardware est assez court (quelques secondes au maximum). Le seul contre exemple que je connaisse, c'est le probe SCSI qui demande d'attendre jusqu'à ~10 secondes par disque, le temps que ceux-ci démare. Sur mes machines non SCSI, le temps de boot du noyau est négligeable (moins de 5 secondes). Mais c'est vrai qu'il n'est pas facilement réductible: je ne vois guère de différence entre une machine à 100 Mhz et une à 3 Ghz, à équipement équivalent, à ce niveau. Une fois qu'on est en mode user, par contre, tout change (à part le temps de chargement et d'initialisation des modules qui est également difficilement optimisable).
Par contre si tu passes ton temps à lancer des myriades de shell scripts au démarrage des services, et compilés en dynamique pour faire bonne mesure, comme sur les RedHat, Mandrake, etc, il ne faut pas s'étonner de ce que ça prenne des plombes.
Je ne voulais même pas parler de ce genre d'horreurs. Je parle juste du temps de lancement et d'initialisation des services en eux mêmes. Si le code est mal optimisé, il sera généralement plus gros, donc mettra à la fois plus de temps à se charger _et_ à s'executer et consomera plus de mémoire. C'est la raison pour laquelle c'est plus visible pour le boot que lors du fonctionnement nominal de la machine.
GP
Jerome Lambert wrote:
(snip)
Tu sais la première chose que j'ai vérifiée ce matin? J'ai voulu savoir si ce message de Ti-Chou n'avait pas été rédigé le 1er avril. Franchement, le jour où je ne pourrai plus rien faire fonctionner parce que je ne compile pas tout avec des flags, je penserai à Gentoo.
Pour le moment...
GP
Jerome Lambert wrote:
(snip)
Tu sais la première chose que j'ai vérifiée ce matin? J'ai voulu savoir si ce
message de Ti-Chou n'avait pas été rédigé le 1er avril. Franchement, le jour
où je ne pourrai plus rien faire fonctionner parce que je ne compile pas tout
avec des flags, je penserai à Gentoo.
Tu sais la première chose que j'ai vérifiée ce matin? J'ai voulu savoir si ce message de Ti-Chou n'avait pas été rédigé le 1er avril. Franchement, le jour où je ne pourrai plus rien faire fonctionner parce que je ne compile pas tout avec des flags, je penserai à Gentoo.
Pour le moment...
GP
Galkine
On Sun, 03 Apr 2005 07:34:05 +0000, Miod Vallat wrote:
Ah oui mais non, l'option debug est listée deux fois. Si tu en enleves une, ça fait tout de suite moins impressionnant... si tu regardes vlc , tu peux rajouter un a un les plugins ,enfin d'après
ce que j'ai compris
On Sun, 03 Apr 2005 07:34:05 +0000, Miod Vallat wrote:
Ah oui mais non, l'option debug est listée deux fois. Si tu en enleves
une, ça fait tout de suite moins impressionnant...
si tu regardes vlc , tu peux rajouter un a un les plugins ,enfin d'après
On Sun, 03 Apr 2005 07:34:05 +0000, Miod Vallat wrote:
Ah oui mais non, l'option debug est listée deux fois. Si tu en enleves une, ça fait tout de suite moins impressionnant... si tu regardes vlc , tu peux rajouter un a un les plugins ,enfin d'après
ce que j'ai compris
Galkine
On Sat, 02 Apr 2005 23:49:33 +0200, Jerome Lambert wrote:
C'est pour moi *le* point névralgique: l'administration passe par des outils clairs et des fichiers correctement documentés, et l'arborescence de /etc est *très* claire, et à mon sens plus claire que Debian. la doc te dit quel fichier modifier et puis il y a debconf
Pour les optimisations, effectivement O2 ou O3 ne change pas fondamentalement la donne (j'en reste souvent à O2 qui est le choix par défaut). Par contre Os fait des merveilles sur des machines à la configuration limitée.
Par contre recompiler mplayer pour l'optimiser, évidemment d'accord.
C'est également un point à mettre à son crédit: on peut recompiler les applications en fonction de la configuration tant matérielle (et activer p.ex. SSE ou Altivec pour les applis qui le supportent) que logicielles (et activer le "support" Gnome des applis qui le supporte). combien de programme tire partie de cela sur la masse ?
on peut aussi le faire avec une debian , et que les mises a jour compile aussi le programme , mais il faut aussi lire la doc
L'avantage justement de Gentoo sur p.ex. Slackware est que l'on définit
une fois pour toutes les optimisations voulues, et les paquets seront compilés suivants les options reconnues, au lieu de tout se palucher paquet par paquet. ah
crafty gcc3.3.4 option de la mort qui tue¹ +20% pour le bench par rapport aux options du makefile gcc3.4.2 le contraire , les options du makefile font mieux que gcc3.3.4 option de la mort qui tue et gcc 3.4.2 option de la mort qui tue est moins bien que gcc3.3.4 option du makefile
il faut noter que crafty n'utilisait pas beaucoup de ram
¹ trouvé sur un forum gentoo
Tout cela donne une distribution sur mesure et parfaitement adaptée au matériel sur lequel elle tourne.
que pense tu d'archlinux ?
On Sat, 02 Apr 2005 23:49:33 +0200, Jerome Lambert wrote:
C'est pour moi *le* point névralgique: l'administration passe par des
outils clairs et des fichiers correctement documentés, et l'arborescence
de /etc est *très* claire, et à mon sens plus claire que Debian.
la doc te dit quel fichier modifier et puis il y a debconf
Pour les optimisations, effectivement O2 ou O3 ne change pas
fondamentalement la donne (j'en reste souvent à O2 qui est le choix par
défaut). Par contre Os fait des merveilles sur des machines à la
configuration limitée.
Par contre recompiler mplayer pour l'optimiser, évidemment d'accord.
C'est également un point à mettre à son crédit: on peut recompiler les
applications en fonction de la configuration tant matérielle (et activer
p.ex. SSE ou Altivec pour les applis qui le supportent) que logicielles
(et activer le "support" Gnome des applis qui le supporte).
combien de programme tire partie de cela sur la masse ?
on peut aussi le faire avec une debian , et que les mises a jour compile
aussi le programme , mais il faut aussi lire la doc
L'avantage justement de Gentoo sur p.ex. Slackware est
que l'on définit
une fois pour toutes les optimisations voulues, et les paquets seront
compilés suivants les options reconnues, au lieu de tout se palucher
paquet par paquet.
ah
crafty gcc3.3.4 option de la mort qui tue¹ +20% pour le bench par
rapport aux options du makefile
gcc3.4.2 le contraire , les options du makefile font mieux que gcc3.3.4
option de la mort qui tue et gcc 3.4.2 option de la mort qui tue est moins
bien que gcc3.3.4 option du makefile
il faut noter que crafty n'utilisait pas beaucoup de ram
¹ trouvé sur un forum gentoo
Tout cela donne une distribution sur mesure et parfaitement adaptée au
matériel sur lequel elle tourne.
On Sat, 02 Apr 2005 23:49:33 +0200, Jerome Lambert wrote:
C'est pour moi *le* point névralgique: l'administration passe par des outils clairs et des fichiers correctement documentés, et l'arborescence de /etc est *très* claire, et à mon sens plus claire que Debian. la doc te dit quel fichier modifier et puis il y a debconf
Pour les optimisations, effectivement O2 ou O3 ne change pas fondamentalement la donne (j'en reste souvent à O2 qui est le choix par défaut). Par contre Os fait des merveilles sur des machines à la configuration limitée.
Par contre recompiler mplayer pour l'optimiser, évidemment d'accord.
C'est également un point à mettre à son crédit: on peut recompiler les applications en fonction de la configuration tant matérielle (et activer p.ex. SSE ou Altivec pour les applis qui le supportent) que logicielles (et activer le "support" Gnome des applis qui le supporte). combien de programme tire partie de cela sur la masse ?
on peut aussi le faire avec une debian , et que les mises a jour compile aussi le programme , mais il faut aussi lire la doc
L'avantage justement de Gentoo sur p.ex. Slackware est que l'on définit
une fois pour toutes les optimisations voulues, et les paquets seront compilés suivants les options reconnues, au lieu de tout se palucher paquet par paquet. ah
crafty gcc3.3.4 option de la mort qui tue¹ +20% pour le bench par rapport aux options du makefile gcc3.4.2 le contraire , les options du makefile font mieux que gcc3.3.4 option de la mort qui tue et gcc 3.4.2 option de la mort qui tue est moins bien que gcc3.3.4 option du makefile
il faut noter que crafty n'utilisait pas beaucoup de ram
¹ trouvé sur un forum gentoo
Tout cela donne une distribution sur mesure et parfaitement adaptée au matériel sur lequel elle tourne.
que pense tu d'archlinux ?
Vincent Bernat
OoO En cette nuit nuageuse du dimanche 03 avril 2005, vers 00:15, Jerome Lambert disait:
- /etc/conf.d/ p.ex. (regroupement des fichiers de configuration système)?
/etc/default ?
- portage plus pratique que apt-get car regroupement thématique des paquets?
apt-get dispose aussi d'un regroupement thématique. Mais il est inutile de donner le thème quand tu veux installer le paquet. -- BOFH excuse #265: The mouse escaped.
OoO En cette nuit nuageuse du dimanche 03 avril 2005, vers 00:15,
Jerome Lambert <jerome.lambert@swing.be> disait:
- /etc/conf.d/ p.ex. (regroupement des fichiers de configuration
système)?
/etc/default ?
- portage plus pratique que apt-get car regroupement thématique des
paquets?
apt-get dispose aussi d'un regroupement thématique. Mais il est
inutile de donner le thème quand tu veux installer le paquet.
--
BOFH excuse #265:
The mouse escaped.
OoO En cette nuit nuageuse du dimanche 03 avril 2005, vers 00:15, Jerome Lambert disait:
- /etc/conf.d/ p.ex. (regroupement des fichiers de configuration système)?
/etc/default ?
- portage plus pratique que apt-get car regroupement thématique des paquets?
apt-get dispose aussi d'un regroupement thématique. Mais il est inutile de donner le thème quand tu veux installer le paquet. -- BOFH excuse #265: The mouse escaped.
Boogabi
Doug713705 wrote:
Le Dimanche 3 Avril 2005 04:49, Boogabi s'est exprimé de la sorte sur fr.comp.os.linux.debats :
L'essayer, c'est l'adopter ;)
J'aurais bien voulu en dire autant (j'ai fais plusieurs tentatives) mais malgré la lecture attentive de la doc et après plusieurs jours de compilation, un nombre conséquent de problèmes de dépendance (!) notament avec Perl j'ai fini par réinstaller Slackware en me disant (à tort ou à raison) que Gentoo n'était pas encore mûre.
Bah j'exagérais ptet avec cette phrase idiote toute faite, mais bon c'est juste mon cas perso :)
Si t'es bien sous SlackWare, tant mieux pour toi... que tout le monde reste où il aime, et qu'il n'essaie autre chose que si la philosophie ou l'utilisation générale parait mieux lui convenir. C'est pour déceler ça que ces discussions peuvent être intérressantes :)
Boogabi (Cédric)
Doug713705 wrote:
Le Dimanche 3 Avril 2005 04:49, Boogabi s'est exprimé de la sorte sur
fr.comp.os.linux.debats :
L'essayer, c'est l'adopter ;)
J'aurais bien voulu en dire autant (j'ai fais plusieurs tentatives) mais
malgré la lecture attentive de la doc et après plusieurs jours de
compilation, un nombre conséquent de problèmes de dépendance (!) notament
avec Perl j'ai fini par réinstaller Slackware en me disant (à tort ou à
raison) que Gentoo n'était pas encore mûre.
Bah j'exagérais ptet avec cette phrase idiote toute faite, mais bon
c'est juste mon cas perso :)
Si t'es bien sous SlackWare, tant mieux pour toi... que tout le monde
reste où il aime, et qu'il n'essaie autre chose que si la philosophie ou
l'utilisation générale parait mieux lui convenir. C'est pour déceler ça
que ces discussions peuvent être intérressantes :)
Le Dimanche 3 Avril 2005 04:49, Boogabi s'est exprimé de la sorte sur fr.comp.os.linux.debats :
L'essayer, c'est l'adopter ;)
J'aurais bien voulu en dire autant (j'ai fais plusieurs tentatives) mais malgré la lecture attentive de la doc et après plusieurs jours de compilation, un nombre conséquent de problèmes de dépendance (!) notament avec Perl j'ai fini par réinstaller Slackware en me disant (à tort ou à raison) que Gentoo n'était pas encore mûre.
Bah j'exagérais ptet avec cette phrase idiote toute faite, mais bon c'est juste mon cas perso :)
Si t'es bien sous SlackWare, tant mieux pour toi... que tout le monde reste où il aime, et qu'il n'essaie autre chose que si la philosophie ou l'utilisation générale parait mieux lui convenir. C'est pour déceler ça que ces discussions peuvent être intérressantes :)
