GCC 3.4.4 est passé stable sur x386 depuis quelques jours et je l'ai
"émergé" sans aller plus loin.
Quelqu'un peut m'expliquer si c'est vraiment important de passer de GCC
3.3.6 à 3.4.4.
J'ai lu l'article expliquant comment mettre correctement à jour GCC, mais
ceci implique une recompilation complète du système, des applications...
Sur un serveur de prod, cela ne me semble risqué, non ?
>>> J'ai pris soin de recompiler le noyau avant de redemarrer la machine. Il ne parlait pas de recompiler le noyau sur le guide de mise à jour, mais dans le doute, j'ai préféré le faire.
Dans la doc on peut lire :"Always use same GCC version for your kernel and additional kernel modules. Once you rebuild your world with new GCC, external modules (like app-emulation/qemu-softmmu) will fail to load. Please rebuild your kernel with new GCC to fix that."
C'est bien ce que je pensais. Tu parles de quelle doc ?
>>> J'ai pris soin de recompiler le noyau avant de redemarrer la machine.
Il ne parlait pas de recompiler le noyau sur le guide de mise à jour,
mais
dans le doute, j'ai préféré le faire.
Dans la doc on peut lire :"Always use same GCC version for your kernel
and
additional kernel modules. Once you rebuild your world with new GCC,
external modules (like app-emulation/qemu-softmmu) will fail to load.
Please rebuild your kernel with new GCC to fix that."
C'est bien ce que je pensais. Tu parles de quelle doc ?
>>> J'ai pris soin de recompiler le noyau avant de redemarrer la machine. Il ne parlait pas de recompiler le noyau sur le guide de mise à jour, mais dans le doute, j'ai préféré le faire.
Dans la doc on peut lire :"Always use same GCC version for your kernel and additional kernel modules. Once you rebuild your world with new GCC, external modules (like app-emulation/qemu-softmmu) will fail to load. Please rebuild your kernel with new GCC to fix that."
C'est bien ce que je pensais. Tu parles de quelle doc ?
Dans la doc on peut lire :"Always use same GCC version for your kernel and additional kernel modules. Once you rebuild your world with new GCC, external modules (like app-emulation/qemu-softmmu) will fail to load. Please rebuild your kernel with new GCC to fix that."
Je me pose tout à coup une question d'ordre existentiel en lisant celà. Le noyau se suffit normalement à lui-même et n'a aucune dépendance avec une quelqconque bibliothèque externe. Je pensais par conséquent que les drivers qui étaient chargés par le noyau suivaient la même règle (mais peut-être n'est-ce pas aussi simple?).
Alors si je comprend tout à fait qu'un soft comme qemu se vautre si le noyau n'est pas compilé avec la même version de GCC que lui, je me demande cependant ce qu'il en est pour un système plus 'classique' (tout le monde ne fait pas de l'émulation). Quelle raison y aurait-il à ce qu'un noyau compilé avec GCC 3.3 ne fonctionne pas correctement sur un système compilé avec la version 3.4 ? J'avoue que j'aimerai bien en comprendre la raison. Si quelqu'un peut m'expliquer celà, je l'en remercie d'avance.
Bonne fin de journée et bon w-e à ceux pour qui ça approche. :-)
-- Christophe Garault Take your marks: Gen too three: Emerge!
-- mailing list
granger@ensil.unilim.fr a écrit :
Dans la doc on peut lire :"Always use same GCC version for your kernel and
additional kernel modules. Once you rebuild your world with new GCC,
external modules (like app-emulation/qemu-softmmu) will fail to load.
Please rebuild your kernel with new GCC to fix that."
Je me pose tout à coup une question d'ordre existentiel en lisant celà.
Le noyau se suffit normalement à lui-même et n'a aucune dépendance avec
une quelqconque bibliothèque externe. Je pensais par conséquent que les
drivers qui étaient chargés par le noyau suivaient la même règle (mais
peut-être n'est-ce pas aussi simple?).
Alors si je comprend tout à fait qu'un soft comme qemu se vautre si le
noyau n'est pas compilé avec la même version de GCC que lui, je me
demande cependant ce qu'il en est pour un système plus 'classique' (tout
le monde ne fait pas de l'émulation). Quelle raison y aurait-il à ce
qu'un noyau compilé avec GCC 3.3 ne fonctionne pas correctement sur un
système compilé avec la version 3.4 ? J'avoue que j'aimerai bien en
comprendre la raison. Si quelqu'un peut m'expliquer celà, je l'en
remercie d'avance.
Bonne fin de journée et bon w-e à ceux pour qui ça approche. :-)
--
Christophe Garault
Take your marks:
Gen too three: Emerge!
Dans la doc on peut lire :"Always use same GCC version for your kernel and additional kernel modules. Once you rebuild your world with new GCC, external modules (like app-emulation/qemu-softmmu) will fail to load. Please rebuild your kernel with new GCC to fix that."
Je me pose tout à coup une question d'ordre existentiel en lisant celà. Le noyau se suffit normalement à lui-même et n'a aucune dépendance avec une quelqconque bibliothèque externe. Je pensais par conséquent que les drivers qui étaient chargés par le noyau suivaient la même règle (mais peut-être n'est-ce pas aussi simple?).
Alors si je comprend tout à fait qu'un soft comme qemu se vautre si le noyau n'est pas compilé avec la même version de GCC que lui, je me demande cependant ce qu'il en est pour un système plus 'classique' (tout le monde ne fait pas de l'émulation). Quelle raison y aurait-il à ce qu'un noyau compilé avec GCC 3.3 ne fonctionne pas correctement sur un système compilé avec la version 3.4 ? J'avoue que j'aimerai bien en comprendre la raison. Si quelqu'un peut m'expliquer celà, je l'en remercie d'avance.
Bonne fin de journée et bon w-e à ceux pour qui ça approche. :-)
-- Christophe Garault Take your marks: Gen too three: Emerge!
-- mailing list
Laurent Steffan
A mon avis, le noyau *et les modules*, ensemble, sont effectivement indépendants du reste du système. Je suis sûr (pour le faire régulièrement, notamment lors d'un chroot) qu'on peut utiliser un noyau compilé par un compilateur avec un système compilé par un autre. En revanche, comme indiqué dans ce texte, on ne peut apparemment pas utiliser des modules (pas seulement qemu-softmmu) compilés avec une version différente de celle qui a servi pour le noyau: ça me semble logique.
Alors après c'est uniquement un problème pratique : est-ce qu'il est plus simple de dissocier dans "world" les programmes applicatifs (et leurs librairies) des modules ? si c'était le cas, ça permettrait de ne pas avoir à recompiler le noyau, mais au prix d'une gestion plus complexe de portage. Je présume qu'il est nettement plus simple - surtout pour des gentooistes - de recompiler le noyau.
Ce sont juste des hypothèses, mais elles me semblent cohérentes. Qu'en pensez-vous ?
Cordialement, Laurent
On 09.12.2005 12:06, Christophe Garault wrote:
a écrit :
Dans la doc on peut lire :"Always use same GCC version for your kernel and additional kernel modules. Once you rebuild your world with new GCC, external modules (like app-emulation/qemu-softmmu) will fail to load. Please rebuild your kernel with new GCC to fix that."
Je me pose tout à coup une question d'ordre existentiel en lisant celà. Le noyau se suffit normalement à lui-même et n'a aucune dépendance avec une quelqconque bibliothèque externe. Je pensais par conséquent que les drivers qui étaient chargés par le noyau suivaient la même règle (mais peut-être n'est-ce pas aussi simple?).
Alors si je comprend tout à fait qu'un soft comme qemu se vautre si le noyau n'est pas compilé avec la même version de GCC que lui, je me demande cependant ce qu'il en est pour un système plus 'classique' (tout le monde ne fait pas de l'émulation). Quelle raison y aurait-il à ce qu'un noyau compilé avec GCC 3.3 ne fonctionne pas correctement sur un système compilé avec la version 3.4 ? J'avoue que j'aimerai bien en comprendre la raison. Si quelqu'un peut m'expliquer celà, je l'en remercie d'avance.
Bonne fin de journée et bon w-e à ceux pour qui ça approche. :-)
-- mailing list
A mon avis, le noyau *et les modules*, ensemble, sont effectivement
indépendants du reste du système. Je suis sûr (pour le faire
régulièrement, notamment lors d'un chroot) qu'on peut utiliser un noyau
compilé par un compilateur avec un système compilé par un autre. En
revanche, comme indiqué dans ce texte, on ne peut apparemment pas
utiliser des modules (pas seulement qemu-softmmu) compilés avec une
version différente de celle qui a servi pour le noyau: ça me semble logique.
Alors après c'est uniquement un problème pratique : est-ce qu'il est
plus simple de dissocier dans "world" les programmes applicatifs (et
leurs librairies) des modules ? si c'était le cas, ça permettrait de ne
pas avoir à recompiler le noyau, mais au prix d'une gestion plus
complexe de portage. Je présume qu'il est nettement plus simple -
surtout pour des gentooistes - de recompiler le noyau.
Ce sont juste des hypothèses, mais elles me semblent cohérentes. Qu'en
pensez-vous ?
Cordialement,
Laurent
On 09.12.2005 12:06, Christophe Garault wrote:
granger@ensil.unilim.fr a écrit :
Dans la doc on peut lire :"Always use same GCC version for your kernel and
additional kernel modules. Once you rebuild your world with new GCC,
external modules (like app-emulation/qemu-softmmu) will fail to load.
Please rebuild your kernel with new GCC to fix that."
Je me pose tout à coup une question d'ordre existentiel en lisant celà.
Le noyau se suffit normalement à lui-même et n'a aucune dépendance avec
une quelqconque bibliothèque externe. Je pensais par conséquent que les
drivers qui étaient chargés par le noyau suivaient la même règle (mais
peut-être n'est-ce pas aussi simple?).
Alors si je comprend tout à fait qu'un soft comme qemu se vautre si le
noyau n'est pas compilé avec la même version de GCC que lui, je me
demande cependant ce qu'il en est pour un système plus 'classique' (tout
le monde ne fait pas de l'émulation). Quelle raison y aurait-il à ce
qu'un noyau compilé avec GCC 3.3 ne fonctionne pas correctement sur un
système compilé avec la version 3.4 ? J'avoue que j'aimerai bien en
comprendre la raison. Si quelqu'un peut m'expliquer celà, je l'en
remercie d'avance.
Bonne fin de journée et bon w-e à ceux pour qui ça approche. :-)
A mon avis, le noyau *et les modules*, ensemble, sont effectivement indépendants du reste du système. Je suis sûr (pour le faire régulièrement, notamment lors d'un chroot) qu'on peut utiliser un noyau compilé par un compilateur avec un système compilé par un autre. En revanche, comme indiqué dans ce texte, on ne peut apparemment pas utiliser des modules (pas seulement qemu-softmmu) compilés avec une version différente de celle qui a servi pour le noyau: ça me semble logique.
Alors après c'est uniquement un problème pratique : est-ce qu'il est plus simple de dissocier dans "world" les programmes applicatifs (et leurs librairies) des modules ? si c'était le cas, ça permettrait de ne pas avoir à recompiler le noyau, mais au prix d'une gestion plus complexe de portage. Je présume qu'il est nettement plus simple - surtout pour des gentooistes - de recompiler le noyau.
Ce sont juste des hypothèses, mais elles me semblent cohérentes. Qu'en pensez-vous ?
Cordialement, Laurent
On 09.12.2005 12:06, Christophe Garault wrote:
a écrit :
Dans la doc on peut lire :"Always use same GCC version for your kernel and additional kernel modules. Once you rebuild your world with new GCC, external modules (like app-emulation/qemu-softmmu) will fail to load. Please rebuild your kernel with new GCC to fix that."
Je me pose tout à coup une question d'ordre existentiel en lisant celà. Le noyau se suffit normalement à lui-même et n'a aucune dépendance avec une quelqconque bibliothèque externe. Je pensais par conséquent que les drivers qui étaient chargés par le noyau suivaient la même règle (mais peut-être n'est-ce pas aussi simple?).
Alors si je comprend tout à fait qu'un soft comme qemu se vautre si le noyau n'est pas compilé avec la même version de GCC que lui, je me demande cependant ce qu'il en est pour un système plus 'classique' (tout le monde ne fait pas de l'émulation). Quelle raison y aurait-il à ce qu'un noyau compilé avec GCC 3.3 ne fonctionne pas correctement sur un système compilé avec la version 3.4 ? J'avoue que j'aimerai bien en comprendre la raison. Si quelqu'un peut m'expliquer celà, je l'en remercie d'avance.
Bonne fin de journée et bon w-e à ceux pour qui ça approche. :-)
-- mailing list
Christophe Garault
Laurent Steffan a écrit :
En revanche, comme indiqué dans ce texte, on ne peut apparemment pas utiliser des modules (pas seulement qemu-softmmu) compilés avec une version différente de celle qui a servi pour le noyau: ça me semble logique.
Dans la mesure ou l'ABI change entre les 2 versions de GCC oui, celà semble logique. Sinon je ne sais pas trop. D'ailleurs j'ignorais même que qemu était un module. ;-)
Je présume qu'il est nettement plus simple - surtout pour des gentooistes - de recompiler le noyau.
Ce sont juste des hypothèses, mais elles me semblent cohérentes. Qu'en pensez-vous ?
En ce qui concerne la machine de tous les jours, celà est effectivement plus simple. Mais quid d'un serveur? On n'a pas toujours le loisir de recompiler le noyau et de rebooter sur des machines de prod. D'ailleurs au vu de l'avancement du GLEP-19, je me demande de plus en plus si Gentoo est vraiment une distrib pour serveur...
Bon w-e. -- Christophe Garault Take your marks: Gen too three: Emerge!
-- mailing list
Laurent Steffan a écrit :
En revanche, comme indiqué dans ce texte, on ne peut apparemment pas
utiliser des modules (pas seulement qemu-softmmu) compilés avec une
version différente de celle qui a servi pour le noyau: ça me semble logique.
Dans la mesure ou l'ABI change entre les 2 versions de GCC oui, celà
semble logique. Sinon je ne sais pas trop. D'ailleurs j'ignorais même
que qemu était un module. ;-)
Je présume qu'il est nettement plus simple -
surtout pour des gentooistes - de recompiler le noyau.
Ce sont juste des hypothèses, mais elles me semblent cohérentes. Qu'en
pensez-vous ?
En ce qui concerne la machine de tous les jours, celà est effectivement
plus simple. Mais quid d'un serveur?
On n'a pas toujours le loisir de recompiler le noyau et de rebooter sur
des machines de prod. D'ailleurs au vu de l'avancement du GLEP-19, je me
demande de plus en plus si Gentoo est vraiment une distrib pour serveur...
Bon w-e.
--
Christophe Garault
Take your marks:
Gen too three: Emerge!
En revanche, comme indiqué dans ce texte, on ne peut apparemment pas utiliser des modules (pas seulement qemu-softmmu) compilés avec une version différente de celle qui a servi pour le noyau: ça me semble logique.
Dans la mesure ou l'ABI change entre les 2 versions de GCC oui, celà semble logique. Sinon je ne sais pas trop. D'ailleurs j'ignorais même que qemu était un module. ;-)
Je présume qu'il est nettement plus simple - surtout pour des gentooistes - de recompiler le noyau.
Ce sont juste des hypothèses, mais elles me semblent cohérentes. Qu'en pensez-vous ?
En ce qui concerne la machine de tous les jours, celà est effectivement plus simple. Mais quid d'un serveur? On n'a pas toujours le loisir de recompiler le noyau et de rebooter sur des machines de prod. D'ailleurs au vu de l'avancement du GLEP-19, je me demande de plus en plus si Gentoo est vraiment une distrib pour serveur...
Bon w-e. -- Christophe Garault Take your marks: Gen too three: Emerge!
-- mailing list
granger
d'après un éfinition :
"ABI Application Binary Interface, a defined interface that includes an API, but adds the further promise that a compiled object file will be portable; no recompilation will be required to move to any supported platform. "
Mon anglais n'est pas des meilleurs sur le plan technique, mais si je comprends l'ABI, c'est l'interface pour les applications. Donc si 2 programmes se basant sur des ABI différentes discutes entre eux, c'est normal qu'il ne se comprennent pas.
ça me fait penser à cette citation de Molière (il me semble :-p ) : "Parle à mon cul,ma tête est malade !". Mais je me trompe peut être d'auteur.
Yannick.
-- mailing list
d'après un éfinition :
"ABI
Application Binary Interface, a defined interface that includes an
API, but adds the further promise that a compiled object file will be
portable; no recompilation will be required to move to any supported
platform.
"
Mon anglais n'est pas des meilleurs sur le plan technique, mais si je
comprends l'ABI, c'est l'interface pour les applications. Donc si 2
programmes se basant sur des ABI différentes discutes entre eux, c'est
normal qu'il ne se comprennent pas.
ça me fait penser à cette citation de Molière (il me semble :-p ) : "Parle
à mon cul,ma tête est malade !". Mais je me trompe peut être d'auteur.
"ABI Application Binary Interface, a defined interface that includes an API, but adds the further promise that a compiled object file will be portable; no recompilation will be required to move to any supported platform. "
Mon anglais n'est pas des meilleurs sur le plan technique, mais si je comprends l'ABI, c'est l'interface pour les applications. Donc si 2 programmes se basant sur des ABI différentes discutes entre eux, c'est normal qu'il ne se comprennent pas.
ça me fait penser à cette citation de Molière (il me semble :-p ) : "Parle à mon cul,ma tête est malade !". Mais je me trompe peut être d'auteur.
Yannick.
-- mailing list
Anthony Jaguenaud
Christophe Garault wrote:
D'ailleurs au vu de l'avancement du GLEP-19, je me demande de plus en plus si Gentoo est vraiment une distrib pour serveur...
Pour moi, la réponse est non. Sans trollé, un serveur à besoin de stabilité, pour ça, la debian est très bien. Mais, il faudrait une vrai mise à jour par an, et changer ta version uniquement si tu as besoin d'un soft plus récent. Sinon, avec les mise à jour de sécurité, tu le garde 2 ou 3 ans sans le changer.
Anthony -- mailing list
Christophe Garault wrote:
D'ailleurs au vu de l'avancement du GLEP-19, je me
demande de plus en plus si Gentoo est vraiment une distrib pour serveur...
Pour moi, la réponse est non. Sans trollé, un serveur à besoin de
stabilité, pour ça, la debian est très bien. Mais, il faudrait une vrai
mise à jour par an, et changer ta version uniquement si tu as besoin
d'un soft plus récent. Sinon, avec les mise à jour de sécurité, tu le
garde 2 ou 3 ans sans le changer.
D'ailleurs au vu de l'avancement du GLEP-19, je me demande de plus en plus si Gentoo est vraiment une distrib pour serveur...
Pour moi, la réponse est non. Sans trollé, un serveur à besoin de stabilité, pour ça, la debian est très bien. Mais, il faudrait une vrai mise à jour par an, et changer ta version uniquement si tu as besoin d'un soft plus récent. Sinon, avec les mise à jour de sécurité, tu le garde 2 ou 3 ans sans le changer.
Anthony -- mailing list
Christophe Garault
Anthony Jaguenaud a écrit :
Pour moi, la réponse est non.
C'est aussi ce que je crois de plus en plus: après 2 ans d'administration d'un petit serveur sous Gentoo, je commence à être las des mises à jours continuelles. Et quand sort une vulnérabilité sur un soft que l'on a pas mis à jour depuis des mois, on se retrouve parfois dans de sales draps à devoir faire l'emerge d'un floppée de dépendances et se taper la doc parce qu'il y a eu plein de changements. Bref, la semaine dernière je n'ai installé que des Sarge! Ceci étant dit, c'est quand même agréable de pouvoir bénéficier des toutes dernières versions. Je pense notamment à PostgreSQL qui passera bientôt en 8.1 alors qu'elle n'en est qu'à la branche 7 sous Debian. Mais alors; comment avoir le beurre et l'argent du beurre sans se priver du sourire de la crémière? ;-)
Bon w-e à tous. -- Christophe Garault Take your marks: Gen too three: Emerge!
-- mailing list
Anthony Jaguenaud a écrit :
Pour moi, la réponse est non.
C'est aussi ce que je crois de plus en plus: après 2 ans
d'administration d'un petit serveur sous Gentoo, je commence à être las
des mises à jours continuelles. Et quand sort une vulnérabilité sur un
soft que l'on a pas mis à jour depuis des mois, on se retrouve parfois
dans de sales draps à devoir faire l'emerge d'un floppée de dépendances
et se taper la doc parce qu'il y a eu plein de changements. Bref, la
semaine dernière je n'ai installé que des Sarge! Ceci étant dit, c'est
quand même agréable de pouvoir bénéficier des toutes dernières versions.
Je pense notamment à PostgreSQL qui passera bientôt en 8.1 alors qu'elle
n'en est qu'à la branche 7 sous Debian. Mais alors; comment avoir le
beurre et l'argent du beurre sans se priver du sourire de la crémière? ;-)
Bon w-e à tous.
--
Christophe Garault
Take your marks:
Gen too three: Emerge!
C'est aussi ce que je crois de plus en plus: après 2 ans d'administration d'un petit serveur sous Gentoo, je commence à être las des mises à jours continuelles. Et quand sort une vulnérabilité sur un soft que l'on a pas mis à jour depuis des mois, on se retrouve parfois dans de sales draps à devoir faire l'emerge d'un floppée de dépendances et se taper la doc parce qu'il y a eu plein de changements. Bref, la semaine dernière je n'ai installé que des Sarge! Ceci étant dit, c'est quand même agréable de pouvoir bénéficier des toutes dernières versions. Je pense notamment à PostgreSQL qui passera bientôt en 8.1 alors qu'elle n'en est qu'à la branche 7 sous Debian. Mais alors; comment avoir le beurre et l'argent du beurre sans se priver du sourire de la crémière? ;-)
Bon w-e à tous. -- Christophe Garault Take your marks: Gen too three: Emerge!
-- mailing list
> Anthony Jaguenaud a écrit :
Pour moi, la réponse est non.
C'est aussi ce que je crois de plus en plus: après 2 ans d'administration d'un petit serveur sous Gentoo, je commence à être las des mises à jours continuelles.
Idem, je ne sais plus trop comment m'y prendre, enfin, aujourd'hui, je l'ai fait au quotidien. Je n'ai que 3 serveurs à administrer, mais j'endosse la casquette d'administrateur alors que ma vraie fonction est développeur. C'est vrai qu'à l'époque ou les serveurs étaient sous Mandrake, je n'avais aucune mise à jour à effectuer (ou peu), mais pas possible d'installer simplement de nouvelles versions de logiciel sans se prendre la tête avec des compilations qui n'allaient jamais jusqu'au bout (je ne suis pas très doué non plus). J'ai choisi la Gentoo après quelques mois de test, j'ai été séduit par son système de mise à jour, sa flexibilité, la disponibilité de version récente de logiciel. Mais finalement, rien ne nous oblige à effectuer toutes les mises à jour ! Juste effectuer les mises à jour de sécurité (glsa-check), et de certaines applications qu'en on souhaite une version plus récente. Je n'ai pas dit trop conneries ?
Et quand sort une vulnérabilité sur un soft que l'on a pas mis à jour depuis des mois, on se retrouve parfois dans de sales draps à devoir faire l'emerge d'un floppée de dépendances et se taper la doc parce qu'il y a eu plein de changements. Bref, la semaine dernière je n'ai installé que des Sarge! Ceci étant dit, c'est quand même agréable de pouvoir bénéficier des toutes dernières versions. Je pense notamment à PostgreSQL qui passera bientôt en 8.1 alors qu'elle n'en est qu'à la branche 7 sous Debian. Mais alors; comment avoir le beurre et l'argent du beurre sans se priver du sourire de la crémière? ;-)
Bon w-e à tous.
Idem, Bon Week à tous.
-- Christophe Garault Take your marks: Gen too three: Emerge!
-- mailing list
-- mailing list
> Anthony Jaguenaud a écrit :
Pour moi, la réponse est non.
C'est aussi ce que je crois de plus en plus: après 2 ans
d'administration d'un petit serveur sous Gentoo, je commence à être las
des mises à jours continuelles.
Idem, je ne sais plus trop comment m'y prendre, enfin, aujourd'hui, je l'ai
fait au quotidien. Je n'ai que 3 serveurs à administrer, mais j'endosse la
casquette d'administrateur alors que ma vraie fonction est développeur.
C'est vrai qu'à l'époque ou les serveurs étaient sous Mandrake, je n'avais
aucune mise à jour à effectuer (ou peu), mais pas possible d'installer
simplement de nouvelles versions de logiciel sans se prendre la tête avec
des compilations qui n'allaient jamais jusqu'au bout (je ne suis pas très
doué non plus). J'ai choisi la Gentoo après quelques mois de test, j'ai été
séduit par son système de mise à jour, sa flexibilité, la disponibilité de
version récente de logiciel. Mais finalement, rien ne nous oblige à
effectuer toutes les mises à jour ! Juste effectuer les mises à jour de
sécurité (glsa-check), et de certaines applications qu'en on souhaite une
version plus récente. Je n'ai pas dit trop conneries ?
Et quand sort une vulnérabilité sur un
soft que l'on a pas mis à jour depuis des mois, on se retrouve parfois
dans de sales draps à devoir faire l'emerge d'un floppée de dépendances
et se taper la doc parce qu'il y a eu plein de changements. Bref, la
semaine dernière je n'ai installé que des Sarge! Ceci étant dit, c'est
quand même agréable de pouvoir bénéficier des toutes dernières versions.
Je pense notamment à PostgreSQL qui passera bientôt en 8.1 alors qu'elle
n'en est qu'à la branche 7 sous Debian. Mais alors; comment avoir le
beurre et l'argent du beurre sans se priver du sourire de la crémière? ;-)
Bon w-e à tous.
Idem, Bon Week à tous.
--
Christophe Garault
Take your marks:
Gen too three: Emerge!
C'est aussi ce que je crois de plus en plus: après 2 ans d'administration d'un petit serveur sous Gentoo, je commence à être las des mises à jours continuelles.
Idem, je ne sais plus trop comment m'y prendre, enfin, aujourd'hui, je l'ai fait au quotidien. Je n'ai que 3 serveurs à administrer, mais j'endosse la casquette d'administrateur alors que ma vraie fonction est développeur. C'est vrai qu'à l'époque ou les serveurs étaient sous Mandrake, je n'avais aucune mise à jour à effectuer (ou peu), mais pas possible d'installer simplement de nouvelles versions de logiciel sans se prendre la tête avec des compilations qui n'allaient jamais jusqu'au bout (je ne suis pas très doué non plus). J'ai choisi la Gentoo après quelques mois de test, j'ai été séduit par son système de mise à jour, sa flexibilité, la disponibilité de version récente de logiciel. Mais finalement, rien ne nous oblige à effectuer toutes les mises à jour ! Juste effectuer les mises à jour de sécurité (glsa-check), et de certaines applications qu'en on souhaite une version plus récente. Je n'ai pas dit trop conneries ?
Et quand sort une vulnérabilité sur un soft que l'on a pas mis à jour depuis des mois, on se retrouve parfois dans de sales draps à devoir faire l'emerge d'un floppée de dépendances et se taper la doc parce qu'il y a eu plein de changements. Bref, la semaine dernière je n'ai installé que des Sarge! Ceci étant dit, c'est quand même agréable de pouvoir bénéficier des toutes dernières versions. Je pense notamment à PostgreSQL qui passera bientôt en 8.1 alors qu'elle n'en est qu'à la branche 7 sous Debian. Mais alors; comment avoir le beurre et l'argent du beurre sans se priver du sourire de la crémière? ;-)
Bon w-e à tous.
Idem, Bon Week à tous.
-- Christophe Garault Take your marks: Gen too three: Emerge!
-- mailing list
-- mailing list
gigi
"parle à mon cul ma tête est malade" , Michael Douglas dans "le syndrome chinois". ...pas sur qu'il l'ai emprunté à JB Poquelin ;-)
On Fri, 2005-12-09 at 16:12 +0100, wrote:
d'après un éfinition :
"ABI Application Binary Interface, a defined interface that includes an API, but adds the further promise that a compiled object file will be portable; no recompilation will be required to move to any supported platform. "
Mon anglais n'est pas des meilleurs sur le plan technique, mais si je comprends l'ABI, c'est l'interface pour les applications. Donc si 2 programmes se basant sur des ABI différentes discutes entre eux, c'est normal qu'il ne se comprennent pas.
ça me fait penser à cette citation de Molière (il me semble :-p ) : "Parle à mon cul,ma tête est malade !". Mais je me trompe peut être d'auteur.
Yannick.
-- mailing list
"parle à mon cul ma tête est malade" , Michael Douglas dans "le syndrome
chinois".
...pas sur qu'il l'ai emprunté à JB Poquelin ;-)
On Fri, 2005-12-09 at 16:12 +0100, granger@ensil.unilim.fr wrote:
d'après un éfinition :
"ABI
Application Binary Interface, a defined interface that includes an
API, but adds the further promise that a compiled object file will be
portable; no recompilation will be required to move to any supported
platform.
"
Mon anglais n'est pas des meilleurs sur le plan technique, mais si je
comprends l'ABI, c'est l'interface pour les applications. Donc si 2
programmes se basant sur des ABI différentes discutes entre eux, c'est
normal qu'il ne se comprennent pas.
ça me fait penser à cette citation de Molière (il me semble :-p ) : "Parle
à mon cul,ma tête est malade !". Mais je me trompe peut être d'auteur.
"parle à mon cul ma tête est malade" , Michael Douglas dans "le syndrome chinois". ...pas sur qu'il l'ai emprunté à JB Poquelin ;-)
On Fri, 2005-12-09 at 16:12 +0100, wrote:
d'après un éfinition :
"ABI Application Binary Interface, a defined interface that includes an API, but adds the further promise that a compiled object file will be portable; no recompilation will be required to move to any supported platform. "
Mon anglais n'est pas des meilleurs sur le plan technique, mais si je comprends l'ABI, c'est l'interface pour les applications. Donc si 2 programmes se basant sur des ABI différentes discutes entre eux, c'est normal qu'il ne se comprennent pas.
ça me fait penser à cette citation de Molière (il me semble :-p ) : "Parle à mon cul,ma tête est malade !". Mais je me trompe peut être d'auteur.
Yannick.
-- mailing list
Antoine Van-Elstraete
Juste pour dire que je suis en train de 'emerge -e system'
et qu'entre "gcc 3.3.4 sans optimisation (-march=i686 -O2 -pipe)" et "gcc 3.4.4 optimisé (-march=k8 -mtune=k8 -mpfmath=sse -pipe -O2 -fomit-frame-pointer)" j'ai pour l'instant 25% d'amélioration sur la vitesse de compilation :)
(je calcule grace à genlop)
-- Antoine Van-Elstraete L1 Info (ULCO) http://www.bluecat.be -- mailing list
Juste pour dire que je suis en train de 'emerge -e system'
et qu'entre "gcc 3.3.4 sans optimisation (-march=i686 -O2 -pipe)" et
"gcc 3.4.4 optimisé (-march=k8 -mtune=k8 -mpfmath=sse -pipe -O2
-fomit-frame-pointer)" j'ai pour l'instant 25% d'amélioration sur la
vitesse de compilation :)
(je calcule grace à genlop)
--
Antoine Van-Elstraete
L1 Info (ULCO)
http://www.bluecat.be
--
gentoo-user-fr@gentoo.org mailing list
Juste pour dire que je suis en train de 'emerge -e system'
et qu'entre "gcc 3.3.4 sans optimisation (-march=i686 -O2 -pipe)" et "gcc 3.4.4 optimisé (-march=k8 -mtune=k8 -mpfmath=sse -pipe -O2 -fomit-frame-pointer)" j'ai pour l'instant 25% d'amélioration sur la vitesse de compilation :)
(je calcule grace à genlop)
-- Antoine Van-Elstraete L1 Info (ULCO) http://www.bluecat.be -- mailing list
