Si je fais 'apt-get -t etch upgrade'
Est-ce que ça fait 'globalement' cette mise à jour ?
a) faire une mise à jour "à la main" avec
'apt-get install kernel****' avec le noyau désiré ?
b) Si on avait soi-même compilé le noyau, il faut se le re-
compiler soi-même. (Ce qui n'est pas mon cas, j'ai toujours
pensé que c'était quelque chose d'absolument impossible à
faire).
c) Si on avait installé des modules particuliers ('madwifi'),
se les remettre soi-même.
Une dernière question, concernant la 'localisation', etc.
Sarge est en 'latin-9' (8859-15). En tout cas la miènne.
Etch est en 'utf-8', c'est ça ? Du moins si on fait une
'installation'. Mais là 'ça' va me garder mes réglages,
donc, pas d'utf-8. Je me souvient pas comment on fait
pour la localisation sous sarge 'dpkg ..... locale' ? Je l'ai
fait récemment, mais impossible de me rappeler. Et avec Etch
ça ne se fait pas de la même manière ?
Si je fais 'apt-get -t etch upgrade'
Est-ce que ça fait 'globalement' cette mise à jour ?
a) faire une mise à jour "à la main" avec
'apt-get install kernel****' avec le noyau désiré ?
b) Si on avait soi-même compilé le noyau, il faut se le re-
compiler soi-même. (Ce qui n'est pas mon cas, j'ai toujours
pensé que c'était quelque chose d'absolument impossible à
faire).
c) Si on avait installé des modules particuliers ('madwifi'),
se les remettre soi-même.
Une dernière question, concernant la 'localisation', etc.
Sarge est en 'latin-9' (8859-15). En tout cas la miènne.
Etch est en 'utf-8', c'est ça ? Du moins si on fait une
'installation'. Mais là 'ça' va me garder mes réglages,
donc, pas d'utf-8. Je me souvient pas comment on fait
pour la localisation sous sarge 'dpkg ..... locale' ? Je l'ai
fait récemment, mais impossible de me rappeler. Et avec Etch
ça ne se fait pas de la même manière ?
Si je fais 'apt-get -t etch upgrade'
Est-ce que ça fait 'globalement' cette mise à jour ?
a) faire une mise à jour "à la main" avec
'apt-get install kernel****' avec le noyau désiré ?
b) Si on avait soi-même compilé le noyau, il faut se le re-
compiler soi-même. (Ce qui n'est pas mon cas, j'ai toujours
pensé que c'était quelque chose d'absolument impossible à
faire).
c) Si on avait installé des modules particuliers ('madwifi'),
se les remettre soi-même.
Une dernière question, concernant la 'localisation', etc.
Sarge est en 'latin-9' (8859-15). En tout cas la miènne.
Etch est en 'utf-8', c'est ça ? Du moins si on fait une
'installation'. Mais là 'ça' va me garder mes réglages,
donc, pas d'utf-8. Je me souvient pas comment on fait
pour la localisation sous sarge 'dpkg ..... locale' ? Je l'ai
fait récemment, mais impossible de me rappeler. Et avec Etch
ça ne se fait pas de la même manière ?
dpkg-reconfigure locales
devrait suffire. Puis il faut éventuellement adapter ses applications:
certains x-terminaux ne supportent pas l'unicode (passer de rxvt à urxvt
par exemple). Il y a un tuto, je crois, sur le wiki Duf.
dpkg-reconfigure locales
devrait suffire. Puis il faut éventuellement adapter ses applications:
certains x-terminaux ne supportent pas l'unicode (passer de rxvt à urxvt
par exemple). Il y a un tuto, je crois, sur le wiki Duf.
dpkg-reconfigure locales
devrait suffire. Puis il faut éventuellement adapter ses applications:
certains x-terminaux ne supportent pas l'unicode (passer de rxvt à urxvt
par exemple). Il y a un tuto, je crois, sur le wiki Duf.
Bonjour,
Le vendredi 13 octobre 2006, Baron Christophe a écrit...
[... mà j Sarge â Etch ...]
La mise à jour ne concerne pas le noyau. [...]
Bonjour,
Le vendredi 13 octobre 2006, Baron Christophe a écrit...
[... mà j Sarge â Etch ...]
La mise à jour ne concerne pas le noyau. [...]
Bonjour,
Le vendredi 13 octobre 2006, Baron Christophe a écrit...
[... mà j Sarge â Etch ...]
La mise à jour ne concerne pas le noyau. [...]
Bonjour la liste.
Un collègue a effectué quelques test pour voir comment ce compo rte
une machine dell contre une machine équivalente Sun sous solaris 10.
Dans sa lancé il a effectué un benchmark entre debian et freebs d sur
2 machines identiques. Il a comparé cela a une machine sous solaris
avec le meme genre de processeur.
En voici les résultats.
test: "time gmake -j3 learn"
[...des sorties de time, une conclusion « catastrophique »...]
Bonjour la liste.
Un collègue a effectué quelques test pour voir comment ce compo rte
une machine dell contre une machine équivalente Sun sous solaris 10.
Dans sa lancé il a effectué un benchmark entre debian et freebs d sur
2 machines identiques. Il a comparé cela a une machine sous solaris
avec le meme genre de processeur.
En voici les résultats.
test: "time gmake -j3 learn"
[...des sorties de time, une conclusion « catastrophique »...]
Bonjour la liste.
Un collègue a effectué quelques test pour voir comment ce compo rte
une machine dell contre une machine équivalente Sun sous solaris 10.
Dans sa lancé il a effectué un benchmark entre debian et freebs d sur
2 machines identiques. Il a comparé cela a une machine sous solaris
avec le meme genre de processeur.
En voici les résultats.
test: "time gmake -j3 learn"
[...des sorties de time, une conclusion « catastrophique »...]
Quand on fait un test, on s'assure que toutes les conditions sont les
mêmes et que seul un petit ensemble de paramètres change.
P.ex. :
??? si on décide de tester plusieurs noyaux, on s'assure que tous les
programmes utilisateur sont exactement les mêmes (ce qui est quasiment
impossible). Pour pseudo-tester entre Linux et FreeBSD, on utilisera
p.ex. un Debian GNU/Linux et une Debian GNU/kFreeBSD ;
??? si on décide de faire le test via une compilation, on s'assure que
les options de compilation sont les mêmes (le passage de -O0 à -O3
peut p.ex. modifier le temps de compilation par un facteur 10), on
s'assure que le code compilé est le même (pas de #ifdef qui omet la
moitié du code), etc.
Quand on fait un test, on s'assure que toutes les conditions sont les
mêmes et que seul un petit ensemble de paramètres change.
P.ex. :
??? si on décide de tester plusieurs noyaux, on s'assure que tous les
programmes utilisateur sont exactement les mêmes (ce qui est quasiment
impossible). Pour pseudo-tester entre Linux et FreeBSD, on utilisera
p.ex. un Debian GNU/Linux et une Debian GNU/kFreeBSD ;
??? si on décide de faire le test via une compilation, on s'assure que
les options de compilation sont les mêmes (le passage de -O0 à -O3
peut p.ex. modifier le temps de compilation par un facteur 10), on
s'assure que le code compilé est le même (pas de #ifdef qui omet la
moitié du code), etc.
Quand on fait un test, on s'assure que toutes les conditions sont les
mêmes et que seul un petit ensemble de paramètres change.
P.ex. :
??? si on décide de tester plusieurs noyaux, on s'assure que tous les
programmes utilisateur sont exactement les mêmes (ce qui est quasiment
impossible). Pour pseudo-tester entre Linux et FreeBSD, on utilisera
p.ex. un Debian GNU/Linux et une Debian GNU/kFreeBSD ;
??? si on décide de faire le test via une compilation, on s'assure que
les options de compilation sont les mêmes (le passage de -O0 à -O3
peut p.ex. modifier le temps de compilation par un facteur 10), on
s'assure que le code compilé est le même (pas de #ifdef qui omet la
moitié du code), etc.
Évidemment, les deux pistes que je suggérait sont idiotes :
l'OP a clairement utilisé gmake à chaque fois, et le temps
système montre que la différence se fait en userland.
Donc, faut chercher ailleurs.
Peut être les version de gmake sont elles très différentes ?
Peut être y avait-il déjà des fichiers produits sur les deux autres
machines ? Lancer "gmake clean all" ou équivalent aurait été plus sur.
Peut être les commandes lancés par les makfiles dépendent t-elles des
distributions ?
Dans tous les cas, comparer l'output précis des commandes serait très
utile. Je demande à voir si c'est possible.
Évidemment, les deux pistes que je suggérait sont idiotes :
l'OP a clairement utilisé gmake à chaque fois, et le temps
système montre que la différence se fait en userland.
Donc, faut chercher ailleurs.
Peut être les version de gmake sont elles très différentes ?
Peut être y avait-il déjà des fichiers produits sur les deux autres
machines ? Lancer "gmake clean all" ou équivalent aurait été plus sur.
Peut être les commandes lancés par les makfiles dépendent t-elles des
distributions ?
Dans tous les cas, comparer l'output précis des commandes serait très
utile. Je demande à voir si c'est possible.
Évidemment, les deux pistes que je suggérait sont idiotes :
l'OP a clairement utilisé gmake à chaque fois, et le temps
système montre que la différence se fait en userland.
Donc, faut chercher ailleurs.
Peut être les version de gmake sont elles très différentes ?
Peut être y avait-il déjà des fichiers produits sur les deux autres
machines ? Lancer "gmake clean all" ou équivalent aurait été plus sur.
Peut être les commandes lancés par les makfiles dépendent t-elles des
distributions ?
Dans tous les cas, comparer l'output précis des commandes serait très
utile. Je demande à voir si c'est possible.
Évidemment, les deux pistes que je suggérait sont idiotes :
l'OP a clairement utilisé gmake à chaque fois, et le temps
système montre que la différence se fait en userland.
Donc, faut chercher ailleurs.
Peut être les version de gmake sont elles très différentes ?
Peut être y avait-il déjà des fichiers produits sur les deux autres
machines ? Lancer "gmake clean all" ou équivalent aurait été plus sur.
Peut être les commandes lancés par les makfiles dépendent t-elles des
distributions ?
Dans tous les cas, comparer l'output précis des commandes serait très
utile. Je demande à voir si c'est possible.
Évidemment, les deux pistes que je suggérait sont idiotes :
l'OP a clairement utilisé gmake à chaque fois, et le temps
système montre que la différence se fait en userland.
Donc, faut chercher ailleurs.
Peut être les version de gmake sont elles très différentes ?
Peut être y avait-il déjà des fichiers produits sur les deux autres
machines ? Lancer "gmake clean all" ou équivalent aurait été plus sur.
Peut être les commandes lancés par les makfiles dépendent t-elles des
distributions ?
Dans tous les cas, comparer l'output précis des commandes serait très
utile. Je demande à voir si c'est possible.
Évidemment, les deux pistes que je suggérait sont idiotes :
l'OP a clairement utilisé gmake à chaque fois, et le temps
système montre que la différence se fait en userland.
Donc, faut chercher ailleurs.
Peut être les version de gmake sont elles très différentes ?
Peut être y avait-il déjà des fichiers produits sur les deux autres
machines ? Lancer "gmake clean all" ou équivalent aurait été plus sur.
Peut être les commandes lancés par les makfiles dépendent t-elles des
distributions ?
Dans tous les cas, comparer l'output précis des commandes serait très
utile. Je demande à voir si c'est possible.
-[ Fri, Oct 13, 2006 at 12:00:24PM +0200, Sylvain Sauvage ]----
> Quand on fait un test, on s'assure que toutes les conditions sont
> les mêmes et que seul un petit ensemble de paramètres change.
> P.ex. :
> ??? si on décide de tester plusieurs noyaux, on s'assure que tous
> les programmes utilisateur sont exactement les mêmes (ce qui est
> quasiment impossible). Pour pseudo-tester entre Linux et FreeBSD,
> on utilisera p.ex. un Debian GNU/Linux et une Debian GNU/kFreeBSD ;
Et si on veut tester une distro globale et pas juste le noyau, on fait
exactement ce que le monsieur à fait.
Je ne vois pas en quoi ce test
est irrecevable.
Au contraire, il est plus intérressant de savoir
comment se comparent entre eux des systèmes complets face aux
commandes de tous les jours que de savoir combien de changement de
contextes peuvent faire un noyau Linux ou BSD par seconde, par
exemple.
> ??? si on décide de faire le test via une compilation, on s'assure
> que les options de compilation sont les mêmes (le passage de -O0 Ã
> -O3 peut p.ex. modifier le temps de compilation par un facteur 10),
> on s'assure que le code compilé est le même (pas de #ifdef qu i omet
> la moitié du code), etc.
L'OP n'a fait que rapporter une petite expérience, dont les rés ultats
lui ont semblé étrange à juste titre et nous devrions le r emercier de
nous en avoir fait part plutôt que de le renvoyer dans les cordes
parcequ'il ne nous plaît pas qu'on dise du mal de notre distro
favorite.
-[ Fri, Oct 13, 2006 at 12:00:24PM +0200, Sylvain Sauvage ]----
> Quand on fait un test, on s'assure que toutes les conditions sont
> les mêmes et que seul un petit ensemble de paramètres change.
> P.ex. :
> ??? si on décide de tester plusieurs noyaux, on s'assure que tous
> les programmes utilisateur sont exactement les mêmes (ce qui est
> quasiment impossible). Pour pseudo-tester entre Linux et FreeBSD,
> on utilisera p.ex. un Debian GNU/Linux et une Debian GNU/kFreeBSD ;
Et si on veut tester une distro globale et pas juste le noyau, on fait
exactement ce que le monsieur à fait.
Je ne vois pas en quoi ce test
est irrecevable.
Au contraire, il est plus intérressant de savoir
comment se comparent entre eux des systèmes complets face aux
commandes de tous les jours que de savoir combien de changement de
contextes peuvent faire un noyau Linux ou BSD par seconde, par
exemple.
> ??? si on décide de faire le test via une compilation, on s'assure
> que les options de compilation sont les mêmes (le passage de -O0 Ã
> -O3 peut p.ex. modifier le temps de compilation par un facteur 10),
> on s'assure que le code compilé est le même (pas de #ifdef qu i omet
> la moitié du code), etc.
L'OP n'a fait que rapporter une petite expérience, dont les rés ultats
lui ont semblé étrange à juste titre et nous devrions le r emercier de
nous en avoir fait part plutôt que de le renvoyer dans les cordes
parcequ'il ne nous plaît pas qu'on dise du mal de notre distro
favorite.
-[ Fri, Oct 13, 2006 at 12:00:24PM +0200, Sylvain Sauvage ]----
> Quand on fait un test, on s'assure que toutes les conditions sont
> les mêmes et que seul un petit ensemble de paramètres change.
> P.ex. :
> ??? si on décide de tester plusieurs noyaux, on s'assure que tous
> les programmes utilisateur sont exactement les mêmes (ce qui est
> quasiment impossible). Pour pseudo-tester entre Linux et FreeBSD,
> on utilisera p.ex. un Debian GNU/Linux et une Debian GNU/kFreeBSD ;
Et si on veut tester une distro globale et pas juste le noyau, on fait
exactement ce que le monsieur à fait.
Je ne vois pas en quoi ce test
est irrecevable.
Au contraire, il est plus intérressant de savoir
comment se comparent entre eux des systèmes complets face aux
commandes de tous les jours que de savoir combien de changement de
contextes peuvent faire un noyau Linux ou BSD par seconde, par
exemple.
> ??? si on décide de faire le test via une compilation, on s'assure
> que les options de compilation sont les mêmes (le passage de -O0 Ã
> -O3 peut p.ex. modifier le temps de compilation par un facteur 10),
> on s'assure que le code compilé est le même (pas de #ifdef qu i omet
> la moitié du code), etc.
L'OP n'a fait que rapporter une petite expérience, dont les rés ultats
lui ont semblé étrange à juste titre et nous devrions le r emercier de
nous en avoir fait part plutôt que de le renvoyer dans les cordes
parcequ'il ne nous plaît pas qu'on dise du mal de notre distro
favorite.