Si l'int=E9r=EAt de recompiler son noyau ne fait aucun doute ;-),
je me pose la question au sujet du buildworld.
Je viens en effet de lire la partie consacr=E9e =E0 ce sujet dans le
handbook,
mais je n'y ai pas per=E7u l'int=E9r=EAt.
Il y est conseill=E9 de refaire le monde avant de refaire son noyau.
Ce que je n'ai pas fait, mon noyau fonctionne plus ou moins bien, mais
admettons.
Cela pourrait-il avoir une cons=E9quence sur les quelques probl=E8mes
rencontr=E9s ici et l=E0 ?
Si l'intérêt de recompiler son noyau ne fait aucun doute ;-),
Mouaif...
je me pose la question au sujet du buildworld. Je viens en effet de lire la partie consacrée à ce sujet dans le handbook, mais je n'y ai pas perçu l'intérêt.
Tant que l'on reste dans une branche stable ou release, cela peut effectivement être considéré comme superflu puisque l'abi du système ne change pas et que par conséquent les binaires fonctionneront correctement avec une version ultérieure du noyau.
Cependant, il faut aussi upgrader suite aux différents SA émis et à moins de bien comprendre ce que l'on fait, il est préférable de passer par une mise à jour binaire ou par un buildworld/buildkernel que par une compilation à la mimine de ce qui a changé (userland & kernel).
Cela pourrait-il avoir une conséquence sur les quelques problèmes rencontrés ici et là ?
Si les sources n'ont pas changé, à moins d'optimisations à la con fournies au compilateur au d'autres joyeusetés du même genre, il n'y a pas de raison.
Dans le cas contraire, suivre ce qui est indiqué dans le handbook ne pourra pas faire de mal et évitera des questions existentielles...
-- "Les neu^H^H^H connectés"?? Peux-tu nous en dire plus. Autant dire que l'on veut muselé les minorités sous des prétexte falacieux avec des méthodes dignes de la Française des jeux!! -+- SM in : <http://www.le-gnu.net> - Bien museler son neuneu -+-
fredmfp@gmail.com writes:
'Lut,
Si l'intérêt de recompiler son noyau ne fait aucun doute ;-),
Mouaif...
je me pose la question au sujet du buildworld.
Je viens en effet de lire la partie consacrée à ce sujet dans le
handbook, mais je n'y ai pas perçu l'intérêt.
Tant que l'on reste dans une branche stable ou release, cela peut
effectivement être considéré comme superflu puisque l'abi du système ne
change pas et que par conséquent les binaires fonctionneront
correctement avec une version ultérieure du noyau.
Cependant, il faut aussi upgrader suite aux différents SA émis et à
moins de bien comprendre ce que l'on fait, il est préférable de passer
par une mise à jour binaire ou par un buildworld/buildkernel que par une
compilation à la mimine de ce qui a changé (userland & kernel).
Cela pourrait-il avoir une conséquence sur les quelques problèmes
rencontrés ici et là ?
Si les sources n'ont pas changé, à moins d'optimisations à la con
fournies au compilateur au d'autres joyeusetés du même genre, il n'y a
pas de raison.
Dans le cas contraire, suivre ce qui est indiqué dans le handbook ne pourra
pas faire de mal et évitera des questions existentielles...
--
"Les neu^H^H^H connectés"?? Peux-tu nous en dire plus.
Autant dire que l'on veut muselé les minorités sous des prétexte
falacieux avec des méthodes dignes de la Française des jeux!!
-+- SM in : <http://www.le-gnu.net> - Bien museler son neuneu -+-
Si l'intérêt de recompiler son noyau ne fait aucun doute ;-),
Mouaif...
je me pose la question au sujet du buildworld. Je viens en effet de lire la partie consacrée à ce sujet dans le handbook, mais je n'y ai pas perçu l'intérêt.
Tant que l'on reste dans une branche stable ou release, cela peut effectivement être considéré comme superflu puisque l'abi du système ne change pas et que par conséquent les binaires fonctionneront correctement avec une version ultérieure du noyau.
Cependant, il faut aussi upgrader suite aux différents SA émis et à moins de bien comprendre ce que l'on fait, il est préférable de passer par une mise à jour binaire ou par un buildworld/buildkernel que par une compilation à la mimine de ce qui a changé (userland & kernel).
Cela pourrait-il avoir une conséquence sur les quelques problèmes rencontrés ici et là ?
Si les sources n'ont pas changé, à moins d'optimisations à la con fournies au compilateur au d'autres joyeusetés du même genre, il n'y a pas de raison.
Dans le cas contraire, suivre ce qui est indiqué dans le handbook ne pourra pas faire de mal et évitera des questions existentielles...
-- "Les neu^H^H^H connectés"?? Peux-tu nous en dire plus. Autant dire que l'on veut muselé les minorités sous des prétexte falacieux avec des méthodes dignes de la Française des jeux!! -+- SM in : <http://www.le-gnu.net> - Bien museler son neuneu -+-
espie
In article , wrote:
Si l'intérêt de recompiler son noyau ne fait aucun doute ;-), Ah ?
je me pose la question au sujet du buildworld. Je viens en effet de lire la partie consacrée à ce sujet dans le handbook, mais je n'y ai pas perçu l'intérêt.
Je ne vois pas de difference majeure entre le noyau et le reste du systeme. Je ne vois pas trop quel peut etre l'interet de recompiler l'un, et pas l'autre. Qu'est-ce que tu y gagnes ? Il y a tout le temps des fonctionnalites ajoutees et des bugs corriges, que ce soit dans le noyau ou ailleurs.
Qu'est-ce que tu fais avec ta machine ? tu achetes du nouveau matos tous les deux jours et tu recompiles ton noyau jusqu'a ce que ca soit supporte ?
Il y est conseillé de refaire le monde avant de refaire son noyau.
Tiens, un conseil FreeBSD non approprie ailleurs...
Ce que je n'ai pas fait, mon noyau fonctionne plus ou moins bien, mais admettons. Cela pourrait-il avoir une conséquence sur les quelques problèmes rencontrés ici et là ?
Ptet ben qu'oui, ptet ben qu'non. Avec autant d'info, que veux-tu qu'on te dise ?
In article <1167749612.249069.120580@h40g2000cwb.googlegroups.com>,
<fredmfp@gmail.com> wrote:
Si l'intérêt de recompiler son noyau ne fait aucun doute ;-),
Ah ?
je me pose la question au sujet du buildworld.
Je viens en effet de lire la partie consacrée à ce sujet dans le
handbook,
mais je n'y ai pas perçu l'intérêt.
Je ne vois pas de difference majeure entre le noyau et le reste du
systeme. Je ne vois pas trop quel peut etre l'interet de recompiler
l'un, et pas l'autre. Qu'est-ce que tu y gagnes ? Il y a tout le temps
des fonctionnalites ajoutees et des bugs corriges, que ce soit dans
le noyau ou ailleurs.
Qu'est-ce que tu fais avec ta machine ? tu achetes du nouveau matos
tous les deux jours et tu recompiles ton noyau jusqu'a ce que ca soit
supporte ?
Il y est conseillé de refaire le monde avant de refaire son noyau.
Tiens, un conseil FreeBSD non approprie ailleurs...
Ce que je n'ai pas fait, mon noyau fonctionne plus ou moins bien, mais
admettons.
Cela pourrait-il avoir une conséquence sur les quelques problèmes
rencontrés ici et là ?
Ptet ben qu'oui, ptet ben qu'non. Avec autant d'info, que veux-tu qu'on
te dise ?
Si l'intérêt de recompiler son noyau ne fait aucun doute ;-), Ah ?
je me pose la question au sujet du buildworld. Je viens en effet de lire la partie consacrée à ce sujet dans le handbook, mais je n'y ai pas perçu l'intérêt.
Je ne vois pas de difference majeure entre le noyau et le reste du systeme. Je ne vois pas trop quel peut etre l'interet de recompiler l'un, et pas l'autre. Qu'est-ce que tu y gagnes ? Il y a tout le temps des fonctionnalites ajoutees et des bugs corriges, que ce soit dans le noyau ou ailleurs.
Qu'est-ce que tu fais avec ta machine ? tu achetes du nouveau matos tous les deux jours et tu recompiles ton noyau jusqu'a ce que ca soit supporte ?
Il y est conseillé de refaire le monde avant de refaire son noyau.
Tiens, un conseil FreeBSD non approprie ailleurs...
Ce que je n'ai pas fait, mon noyau fonctionne plus ou moins bien, mais admettons. Cela pourrait-il avoir une conséquence sur les quelques problèmes rencontrés ici et là ?
Ptet ben qu'oui, ptet ben qu'non. Avec autant d'info, que veux-tu qu'on te dise ?
Stephane Catteau
devait dire quelque chose comme ceci :
Si l'intérêt de recompiler son noyau ne fait aucun doute ;-), je me pose la question au sujet du buildworld. Je viens en effet de lire la partie consacrée à ce sujet dans le handbook, mais je n'y ai pas perçu l'intérêt.
Le même que l'intérêt qu'il y a à recompiler le noyau, c'est-à-dire un intérêt limité. En fait, la question serait plutôt quel est l'intérêt de ne pas refaire le monde en même temps que tu recompiles le noyau ? Etant entendu que ce n'est pas une chose que tu fais tous les mois, et encore moins tous les deux jours. Personnellement, c'est une habitude que j'ai prise. J'installe à partir d'une ISO de la bonne version, je configure vite fait pour que le système soit utilisable. Un petit coup de cvsup pour mettre les sources à jour, dans la foulée puisque j'en suis là, j'en profite pour alléger un peu le noyau, et je recompile le tout. Après les machines peuvent tourner un an, voir plus, sans mise à jour autre que celles de sécurité, et encore lorsqu'elles concerne mon cas de figure. Mais bon, c'est vraiment juste histoire d'avoir un système tout frais au moment de l'installation, et c'est la seule fois où je le fais.
[snip]
Cela pourrait-il avoir une conséquence sur les quelques problèmes rencontrés ici et là ?
Recompiler le noyau sans refaire le monde ne peut avoir que des conséquences négatives. Ca ne veut pas dire qu'il y en aura, mais s'il y en a, elles n'iront assurément pas dans le sens d'un système plus stable. Ayant par manque de temps et non support de la carte réseau par GENERIC, fait tourner deux semaines une machine avec un noyau et un monde qui n'étaient pas synchrone, la seule conséquence que j'ai vue, c'était la disparition de procfs. Autant dire que ça ne dérange pas le moins du monde.
Merci d'avance.
De rien.
fredmfp@gmail.com devait dire quelque chose comme ceci :
Si l'intérêt de recompiler son noyau ne fait aucun doute ;-),
je me pose la question au sujet du buildworld.
Je viens en effet de lire la partie consacrée à ce sujet dans le
handbook, mais je n'y ai pas perçu l'intérêt.
Le même que l'intérêt qu'il y a à recompiler le noyau, c'est-à-dire un
intérêt limité. En fait, la question serait plutôt quel est l'intérêt
de ne pas refaire le monde en même temps que tu recompiles le noyau ?
Etant entendu que ce n'est pas une chose que tu fais tous les mois, et
encore moins tous les deux jours.
Personnellement, c'est une habitude que j'ai prise. J'installe à
partir d'une ISO de la bonne version, je configure vite fait pour que
le système soit utilisable. Un petit coup de cvsup pour mettre les
sources à jour, dans la foulée puisque j'en suis là, j'en profite pour
alléger un peu le noyau, et je recompile le tout. Après les machines
peuvent tourner un an, voir plus, sans mise à jour autre que celles de
sécurité, et encore lorsqu'elles concerne mon cas de figure.
Mais bon, c'est vraiment juste histoire d'avoir un système tout frais
au moment de l'installation, et c'est la seule fois où je le fais.
[snip]
Cela pourrait-il avoir une conséquence sur les quelques problèmes
rencontrés ici et là ?
Recompiler le noyau sans refaire le monde ne peut avoir que des
conséquences négatives. Ca ne veut pas dire qu'il y en aura, mais s'il
y en a, elles n'iront assurément pas dans le sens d'un système plus
stable. Ayant par manque de temps et non support de la carte réseau par
GENERIC, fait tourner deux semaines une machine avec un noyau et un
monde qui n'étaient pas synchrone, la seule conséquence que j'ai vue,
c'était la disparition de procfs. Autant dire que ça ne dérange pas le
moins du monde.
Si l'intérêt de recompiler son noyau ne fait aucun doute ;-), je me pose la question au sujet du buildworld. Je viens en effet de lire la partie consacrée à ce sujet dans le handbook, mais je n'y ai pas perçu l'intérêt.
Le même que l'intérêt qu'il y a à recompiler le noyau, c'est-à-dire un intérêt limité. En fait, la question serait plutôt quel est l'intérêt de ne pas refaire le monde en même temps que tu recompiles le noyau ? Etant entendu que ce n'est pas une chose que tu fais tous les mois, et encore moins tous les deux jours. Personnellement, c'est une habitude que j'ai prise. J'installe à partir d'une ISO de la bonne version, je configure vite fait pour que le système soit utilisable. Un petit coup de cvsup pour mettre les sources à jour, dans la foulée puisque j'en suis là, j'en profite pour alléger un peu le noyau, et je recompile le tout. Après les machines peuvent tourner un an, voir plus, sans mise à jour autre que celles de sécurité, et encore lorsqu'elles concerne mon cas de figure. Mais bon, c'est vraiment juste histoire d'avoir un système tout frais au moment de l'installation, et c'est la seule fois où je le fais.
[snip]
Cela pourrait-il avoir une conséquence sur les quelques problèmes rencontrés ici et là ?
Recompiler le noyau sans refaire le monde ne peut avoir que des conséquences négatives. Ca ne veut pas dire qu'il y en aura, mais s'il y en a, elles n'iront assurément pas dans le sens d'un système plus stable. Ayant par manque de temps et non support de la carte réseau par GENERIC, fait tourner deux semaines une machine avec un noyau et un monde qui n'étaient pas synchrone, la seule conséquence que j'ai vue, c'était la disparition de procfs. Autant dire que ça ne dérange pas le moins du monde.
Merci d'avance.
De rien.
Stephane Catteau
fred devait dire quelque chose comme ceci :
Le même que l'intérêt qu'il y a à recompiler le noyau, c'est-à-dire un intérêt limité. En fait, la question serait plutôt quel est l'intérêt de ne pas refaire le monde en même temps que tu recompiles le noyau ?
Ah bah j'y vais mollo, hein, chaque chose en son temps.
Bof. Ce n'est pas plus compliqué que recompiler le noyau. Au contraire même, puisque le noyau tu peux toujours le planter en retirant quelque chose de fondamental pour ta machine. Et là il faut parfois que tu commences à jongler avec l'ancien noyau, le nouveau noyau, un live-CD et google, pour t'en sortir. A la limite, quitte à commencer, c'est plutôt en recompilant le monde, et GENERIC dans le même temps, qu'il faudrait le faire.
Merci donc.
De rien.
fred devait dire quelque chose comme ceci :
Le même que l'intérêt qu'il y a à recompiler le noyau, c'est-à-dire un
intérêt limité. En fait, la question serait plutôt quel est l'intérêt
de ne pas refaire le monde en même temps que tu recompiles le noyau ?
Ah bah j'y vais mollo, hein, chaque chose en son temps.
Bof. Ce n'est pas plus compliqué que recompiler le noyau. Au contraire
même, puisque le noyau tu peux toujours le planter en retirant quelque
chose de fondamental pour ta machine. Et là il faut parfois que tu
commences à jongler avec l'ancien noyau, le nouveau noyau, un live-CD
et google, pour t'en sortir.
A la limite, quitte à commencer, c'est plutôt en recompilant le monde,
et GENERIC dans le même temps, qu'il faudrait le faire.
Le même que l'intérêt qu'il y a à recompiler le noyau, c'est-à-dire un intérêt limité. En fait, la question serait plutôt quel est l'intérêt de ne pas refaire le monde en même temps que tu recompiles le noyau ?
Ah bah j'y vais mollo, hein, chaque chose en son temps.
Bof. Ce n'est pas plus compliqué que recompiler le noyau. Au contraire même, puisque le noyau tu peux toujours le planter en retirant quelque chose de fondamental pour ta machine. Et là il faut parfois que tu commences à jongler avec l'ancien noyau, le nouveau noyau, un live-CD et google, pour t'en sortir. A la limite, quitte à commencer, c'est plutôt en recompilant le monde, et GENERIC dans le même temps, qu'il faudrait le faire.
Merci donc.
De rien.
Stephane Catteau
fred devait dire quelque chose comme ceci :
Par contre, mon noyau est maintenant postfixé par p11. patch #11 ?
Je vais peut-être dire une connerie, mais il me semble que les 'pXY' désigne la sous-version d'une même release. Donc d'une certaine façon oui, on peut dire "patch #11', même si amha "11ème revision" me semblerait plus adapté.
fred devait dire quelque chose comme ceci :
Par contre, mon noyau est maintenant postfixé par p11.
patch #11 ?
Je vais peut-être dire une connerie, mais il me semble que les 'pXY'
désigne la sous-version d'une même release. Donc d'une certaine façon
oui, on peut dire "patch #11', même si amha "11ème revision" me
semblerait plus adapté.
Par contre, mon noyau est maintenant postfixé par p11. patch #11 ?
Je vais peut-être dire une connerie, mais il me semble que les 'pXY' désigne la sous-version d'une même release. Donc d'une certaine façon oui, on peut dire "patch #11', même si amha "11ème revision" me semblerait plus adapté.
Eric Masson
fred writes:
'Lut,
Par contre, mon noyau est maintenant postfixé par p11. patch #11 ?
Patchlevel 11, ce qui signifie que 11 modifications liées à des problèmes de sécurité ou de stabilité ont été apportées à la branche 6.1 depuis qu'elle a été publiée.
Les différents problèmes corrigés sont mentionnés dans : /usr/src/UPDATING
Bon, j'aurais tjrs gagné un monde tout neuf...
Avec quelques corrections sur openssl, openssh, bind, gzip, sendmail, ypserv.
-- C'est quoi tout ces batards qui contactent "abuse" pour trois fois rien car ils n' ont pas de couilles pour régler leur problémes eux mêmes. C'est pire qu'aux USA où on porte plainte pour un rien!!! -+- Dch2 in GNU - Viens là que je te spamme la gueule -+-
fred <fredantispam@free.fr> writes:
'Lut,
Par contre, mon noyau est maintenant postfixé par p11.
patch #11 ?
Patchlevel 11, ce qui signifie que 11 modifications liées à des
problèmes de sécurité ou de stabilité ont été apportées à la branche 6.1
depuis qu'elle a été publiée.
Les différents problèmes corrigés sont mentionnés dans :
/usr/src/UPDATING
Bon, j'aurais tjrs gagné un monde tout neuf...
Avec quelques corrections sur openssl, openssh, bind, gzip, sendmail,
ypserv.
--
C'est quoi tout ces batards qui contactent "abuse" pour trois fois rien
car ils n' ont pas de couilles pour régler leur problémes eux mêmes.
C'est pire qu'aux USA où on porte plainte pour un rien!!!
-+- Dch2 in GNU - Viens là que je te spamme la gueule -+-
Par contre, mon noyau est maintenant postfixé par p11. patch #11 ?
Patchlevel 11, ce qui signifie que 11 modifications liées à des problèmes de sécurité ou de stabilité ont été apportées à la branche 6.1 depuis qu'elle a été publiée.
Les différents problèmes corrigés sont mentionnés dans : /usr/src/UPDATING
Bon, j'aurais tjrs gagné un monde tout neuf...
Avec quelques corrections sur openssl, openssh, bind, gzip, sendmail, ypserv.
-- C'est quoi tout ces batards qui contactent "abuse" pour trois fois rien car ils n' ont pas de couilles pour régler leur problémes eux mêmes. C'est pire qu'aux USA où on porte plainte pour un rien!!! -+- Dch2 in GNU - Viens là que je te spamme la gueule -+-
Benoit Izac
Bonjour,
le 02/01/2007 à 23:01, fred a écrit dans le message :
Par contre, mon noyau est maintenant postfixé par p11. patch #11 ?
Oui, sauf que ça ne concerne pas seulement le noyau.
Bon, j'aurais tjrs gagné un monde tout neuf...
Ça dépend...
Lorsque l'on fait un cvsup, on voit s'afficher la liste des fichiers mis à jour, ça donne déjà une bonne idée de ce qu'il doit être fait. En partant d'une release récente, il n'y a parfois rien à faire. À ce jour, en partant d'une 6.1 (qui va fêter ces huit mois), il est nécessaire de tout recompiler.
À mon avis, avant de faire quoique ce soit, il faut déjà bien lire le(s) bulletin(s) de sécurité. Il y a des cas ou la recompilation du noyau ne sert strictement à rien ; par exemple le dernier bulletin (gtar) où un simple patch puis compilation/installation de tar suffisent à résoudre complètement le problème. Dans d'autre cas (openssl par exemple) un make world est indispensable et finalement lorsque les failles concernent le noyau, seul celui-ci doit être recompilé/installé (et tant pis pour l'uptime).
Bien évidemment tout cela ne concerne que les personnes qui suivent les release (tag RELENG_X_Y) et ne s'applique pas pour ceux qui préfèrent les versions STABLE/CURRENT où une mise à jour implique souvent de tout refaire.
Ne pas oublier non plus de mettre à jour les ports vulnérables ; pour cette tâche, un outil comme security/portaudit est plus qu'appréciable si l'on veut éviter de tout recompiler.
-- Benoit Izac
Bonjour,
le 02/01/2007 à 23:01, fred a écrit dans le message
<87bqlh84w4.fsf@free.fr> :
Par contre, mon noyau est maintenant postfixé par p11.
patch #11 ?
Oui, sauf que ça ne concerne pas seulement le noyau.
Bon, j'aurais tjrs gagné un monde tout neuf...
Ça dépend...
Lorsque l'on fait un cvsup, on voit s'afficher la liste des fichiers mis
à jour, ça donne déjà une bonne idée de ce qu'il doit être fait. En
partant d'une release récente, il n'y a parfois rien à faire. À ce jour,
en partant d'une 6.1 (qui va fêter ces huit mois), il est nécessaire de
tout recompiler.
À mon avis, avant de faire quoique ce soit, il faut déjà bien lire le(s)
bulletin(s) de sécurité. Il y a des cas ou la recompilation du noyau ne
sert strictement à rien ; par exemple le dernier bulletin (gtar) où un
simple patch puis compilation/installation de tar suffisent à résoudre
complètement le problème. Dans d'autre cas (openssl par exemple) un make
world est indispensable et finalement lorsque les failles concernent le
noyau, seul celui-ci doit être recompilé/installé (et tant pis pour
l'uptime).
Bien évidemment tout cela ne concerne que les personnes qui suivent les
release (tag RELENG_X_Y) et ne s'applique pas pour ceux qui préfèrent
les versions STABLE/CURRENT où une mise à jour implique souvent de tout
refaire.
Ne pas oublier non plus de mettre à jour les ports vulnérables ; pour
cette tâche, un outil comme security/portaudit est plus qu'appréciable
si l'on veut éviter de tout recompiler.
le 02/01/2007 à 23:01, fred a écrit dans le message :
Par contre, mon noyau est maintenant postfixé par p11. patch #11 ?
Oui, sauf que ça ne concerne pas seulement le noyau.
Bon, j'aurais tjrs gagné un monde tout neuf...
Ça dépend...
Lorsque l'on fait un cvsup, on voit s'afficher la liste des fichiers mis à jour, ça donne déjà une bonne idée de ce qu'il doit être fait. En partant d'une release récente, il n'y a parfois rien à faire. À ce jour, en partant d'une 6.1 (qui va fêter ces huit mois), il est nécessaire de tout recompiler.
À mon avis, avant de faire quoique ce soit, il faut déjà bien lire le(s) bulletin(s) de sécurité. Il y a des cas ou la recompilation du noyau ne sert strictement à rien ; par exemple le dernier bulletin (gtar) où un simple patch puis compilation/installation de tar suffisent à résoudre complètement le problème. Dans d'autre cas (openssl par exemple) un make world est indispensable et finalement lorsque les failles concernent le noyau, seul celui-ci doit être recompilé/installé (et tant pis pour l'uptime).
Bien évidemment tout cela ne concerne que les personnes qui suivent les release (tag RELENG_X_Y) et ne s'applique pas pour ceux qui préfèrent les versions STABLE/CURRENT où une mise à jour implique souvent de tout refaire.
Ne pas oublier non plus de mettre à jour les ports vulnérables ; pour cette tâche, un outil comme security/portaudit est plus qu'appréciable si l'on veut éviter de tout recompiler.
-- Benoit Izac
Eric Masson
fred writes:
'Re,
le handbook mentionne bien la différence entre STABLE et CURRENT. Mais ma foi, je n'ai pas bien compris la relation avec RELENG_X_Y, déjà abordé ici au demeurant.
STABLE c'est actuellement RELENG_6 (RELENG_5 aussi tant que cette branche est maintenue en parallèle à RELENG_6, même si son utilisation est déconseillée au profit de la plus récente)
RELENG_6_Y est une branche correspondant à une release de la branche 6.x, initialement créée par l'équipe en charge de la gestion des releases. Une fois la release effectuée, le contrôle est passé à l'officier de sécurité du projet.
Cela signifie que, sur cette branche, tout commit pre release doit avoir été approuvé par re@ et que tout commit post release doit avoir été approuvé par security@, ce qui permet de maintenir cette release à jour en termes de sécurité tant qu'elle est supportée par security@
Que puis-je déduire de uname -a : FreeBSD marsu 6.1-RELEASE-p11 FreeBSD 6.1-RELEASE-p11 #3: Tue Jan 2 22:33:39 CET 2007 :/usr/obj/usr/src/sys/FREEBSD_61 i386
RELENG_6_1
Voir les liens suivants : http://www.freebsd.org/releng/index.html http://www.freebsd.org/security/#adv
--
A l'heure actuelle, il s'est formé une sorte "d'aristocratie" de Linux qui essaye de maintenir ses connaissances pour elles et d'en priver les autres en innondant chaque débutant de documentations -+- EF in Guide du liuxien pervers : "Comprenne qui pourra..." -+-
fred <fredantispam@free.fr> writes:
'Re,
le handbook mentionne bien la différence entre STABLE et CURRENT.
Mais ma foi, je n'ai pas bien compris la relation avec RELENG_X_Y,
déjà abordé ici au demeurant.
STABLE c'est actuellement RELENG_6 (RELENG_5 aussi tant que cette
branche est maintenue en parallèle à RELENG_6, même si son utilisation
est déconseillée au profit de la plus récente)
RELENG_6_Y est une branche correspondant à une release de la branche
6.x, initialement créée par l'équipe en charge de la gestion des
releases. Une fois la release effectuée, le contrôle est passé à
l'officier de sécurité du projet.
Cela signifie que, sur cette branche, tout commit pre release doit avoir
été approuvé par re@ et que tout commit post release doit avoir été
approuvé par security@, ce qui permet de maintenir cette release à jour
en termes de sécurité tant qu'elle est supportée par security@
Que puis-je déduire de uname -a :
FreeBSD marsu 6.1-RELEASE-p11 FreeBSD 6.1-RELEASE-p11 #3: Tue Jan 2 22:33:39 CET 2007 root@marsu:/usr/obj/usr/src/sys/FREEBSD_61 i386
RELENG_6_1
Voir les liens suivants :
http://www.freebsd.org/releng/index.html
http://www.freebsd.org/security/#adv
--
A l'heure actuelle, il s'est formé une sorte "d'aristocratie" de Linux
qui essaye de maintenir ses connaissances pour elles et d'en priver les
autres en innondant chaque débutant de documentations
-+- EF in Guide du liuxien pervers : "Comprenne qui pourra..." -+-
le handbook mentionne bien la différence entre STABLE et CURRENT. Mais ma foi, je n'ai pas bien compris la relation avec RELENG_X_Y, déjà abordé ici au demeurant.
STABLE c'est actuellement RELENG_6 (RELENG_5 aussi tant que cette branche est maintenue en parallèle à RELENG_6, même si son utilisation est déconseillée au profit de la plus récente)
RELENG_6_Y est une branche correspondant à une release de la branche 6.x, initialement créée par l'équipe en charge de la gestion des releases. Une fois la release effectuée, le contrôle est passé à l'officier de sécurité du projet.
Cela signifie que, sur cette branche, tout commit pre release doit avoir été approuvé par re@ et que tout commit post release doit avoir été approuvé par security@, ce qui permet de maintenir cette release à jour en termes de sécurité tant qu'elle est supportée par security@
Que puis-je déduire de uname -a : FreeBSD marsu 6.1-RELEASE-p11 FreeBSD 6.1-RELEASE-p11 #3: Tue Jan 2 22:33:39 CET 2007 :/usr/obj/usr/src/sys/FREEBSD_61 i386
RELENG_6_1
Voir les liens suivants : http://www.freebsd.org/releng/index.html http://www.freebsd.org/security/#adv
--
A l'heure actuelle, il s'est formé une sorte "d'aristocratie" de Linux qui essaye de maintenir ses connaissances pour elles et d'en priver les autres en innondant chaque débutant de documentations -+- EF in Guide du liuxien pervers : "Comprenne qui pourra..." -+-
Marwan Burelle
On Tue, 02 Jan 2007 17:56:16 +0100 fred wrote:
Ptet ben qu'oui, ptet ben qu'non. Avec autant d'info, que veux-tu qu'on te dise ? Hmmm, il me semble avoir donné suffisamment d'infos dans mes posts
précédents ;-)
Je penses que Marc faisait une allusion (cachée) au fait que tu fais un poste spécifique FreeBSD sans le précisé (encore, dirait-il ;) ses réponses sont dans l'esprit d'une question d'ordre générale et non spécifique à FreeBSD, de même pour cette remarque finale.
Je profite de mon premier message de l'année pour vous souhaitez une bonne année (c'est bien, mon sevrage progressif des news se passe pas trop mal, mon premier poste de 2007 est le 3 janvier ... )
-- Ferengi Rule of Acquisition #214: Never begin a negotiation on an empty stomach. -- ST:DS9, "The Maquis, Part I"
On Tue, 02 Jan 2007 17:56:16 +0100
fred <fredantispam@free.fr> wrote:
Ptet ben qu'oui, ptet ben qu'non. Avec autant d'info, que veux-tu
qu'on te dise ?
Hmmm, il me semble avoir donné suffisamment d'infos dans mes posts
précédents ;-)
Je penses que Marc faisait une allusion (cachée) au fait que tu fais un
poste spécifique FreeBSD sans le précisé (encore, dirait-il ;) ses
réponses sont dans l'esprit d'une question d'ordre générale et non
spécifique à FreeBSD, de même pour cette remarque finale.
Je profite de mon premier message de l'année pour vous souhaitez une
bonne année (c'est bien, mon sevrage progressif des news se passe pas
trop mal, mon premier poste de 2007 est le 3 janvier ... )
--
Ferengi Rule of Acquisition #214:
Never begin a negotiation on an empty stomach.
-- ST:DS9, "The Maquis, Part I"
Ptet ben qu'oui, ptet ben qu'non. Avec autant d'info, que veux-tu qu'on te dise ? Hmmm, il me semble avoir donné suffisamment d'infos dans mes posts
précédents ;-)
Je penses que Marc faisait une allusion (cachée) au fait que tu fais un poste spécifique FreeBSD sans le précisé (encore, dirait-il ;) ses réponses sont dans l'esprit d'une question d'ordre générale et non spécifique à FreeBSD, de même pour cette remarque finale.
Je profite de mon premier message de l'année pour vous souhaitez une bonne année (c'est bien, mon sevrage progressif des news se passe pas trop mal, mon premier poste de 2007 est le 3 janvier ... )
-- Ferengi Rule of Acquisition #214: Never begin a negotiation on an empty stomach. -- ST:DS9, "The Maquis, Part I"
Marwan Burelle
On 2 Jan 2007 06:53:32 -0800 wrote:
Bonjour,
Si l'intérêt de recompiler son noyau ne fait aucun doute ;-), je me pose la question au sujet du buildworld. Je viens en effet de lire la partie consacrée à ce sujet dans le handbook, mais je n'y ai pas perçu l'intérêt.
J'ai déjà dû te faire l'explication base/reste, donc je ne recommence pas. Par contre, je vais ré-éclaircir les détails sur cette histoire de monde et de noyau.
Premier point, contrairement à Linux l'évolution du monde et du noyau ne sont pas séparées, au pire certains éléments sont importés (on parle de "third partie") mais leur intégration est tout de même réalisée par l'équipe de FreeBSD (ou d'ailleurs l'équipe d'Open, ou de Net, cette remarque marche avec les 3.)
Par conséquent, il y a une plus grande adéquation/dépendance entre le monde et le noyau. Le point le plus "visible" est la chaîne d'outil de compilation, si la version n'est pas assez à jour il peut y avoir un problème lors de la compilation du noyau (si je ne dis pas de bêtise, sur un FreeBSD, un make buildkernel sur des sources "propres" utilisera les versions installées de gcc et ses amis, tandis qu'après un buildworld il utilisera ceux fraîchement compilés.)
Après, toutes les mises à jour ne nécessite pas de re-compilation du monde. En gros, dans le cas des màj d'une release (RELENG_6_1 par exemple) /usr/src/UPDATING indique ce qui a été changé et les alertes de sécu indique s'il faut tout recompiler ou bien si juste la partie incriminée suffit. Dans le cas de -STABLE (RELENG_6), mieux toute recompiler, c'est plus simple. Idem pour CURRENT.
Pour finir, bien évidement tu peux recompiler le noyau sans le monde si tu n'as pas mis tes sources à jour, ça n'aura pas d'incidence.
-- BOFH excuse #254:
Interference from lunar radiation
On 2 Jan 2007 06:53:32 -0800
fredmfp@gmail.com wrote:
Bonjour,
Si l'intérêt de recompiler son noyau ne fait aucun doute ;-),
je me pose la question au sujet du buildworld.
Je viens en effet de lire la partie consacrée à ce sujet dans le
handbook,
mais je n'y ai pas perçu l'intérêt.
J'ai déjà dû te faire l'explication base/reste, donc je ne recommence
pas. Par contre, je vais ré-éclaircir les détails sur cette histoire de
monde et de noyau.
Premier point, contrairement à Linux l'évolution du monde et du noyau
ne sont pas séparées, au pire certains éléments sont importés (on parle
de "third partie") mais leur intégration est tout de même réalisée par
l'équipe de FreeBSD (ou d'ailleurs l'équipe d'Open, ou de Net, cette
remarque marche avec les 3.)
Par conséquent, il y a une plus grande adéquation/dépendance entre le
monde et le noyau. Le point le plus "visible" est la chaîne d'outil de
compilation, si la version n'est pas assez à jour il peut y avoir un
problème lors de la compilation du noyau (si je ne dis pas de bêtise,
sur un FreeBSD, un make buildkernel sur des sources "propres" utilisera
les versions installées de gcc et ses amis, tandis qu'après un
buildworld il utilisera ceux fraîchement compilés.)
Après, toutes les mises à jour ne nécessite pas de re-compilation du
monde. En gros, dans le cas des màj d'une release (RELENG_6_1 par
exemple) /usr/src/UPDATING indique ce qui a été changé et les alertes
de sécu indique s'il faut tout recompiler ou bien si juste la partie
incriminée suffit. Dans le cas de -STABLE (RELENG_6), mieux toute
recompiler, c'est plus simple. Idem pour CURRENT.
Pour finir, bien évidement tu peux recompiler le noyau sans le monde si
tu n'as pas mis tes sources à jour, ça n'aura pas d'incidence.
Si l'intérêt de recompiler son noyau ne fait aucun doute ;-), je me pose la question au sujet du buildworld. Je viens en effet de lire la partie consacrée à ce sujet dans le handbook, mais je n'y ai pas perçu l'intérêt.
J'ai déjà dû te faire l'explication base/reste, donc je ne recommence pas. Par contre, je vais ré-éclaircir les détails sur cette histoire de monde et de noyau.
Premier point, contrairement à Linux l'évolution du monde et du noyau ne sont pas séparées, au pire certains éléments sont importés (on parle de "third partie") mais leur intégration est tout de même réalisée par l'équipe de FreeBSD (ou d'ailleurs l'équipe d'Open, ou de Net, cette remarque marche avec les 3.)
Par conséquent, il y a une plus grande adéquation/dépendance entre le monde et le noyau. Le point le plus "visible" est la chaîne d'outil de compilation, si la version n'est pas assez à jour il peut y avoir un problème lors de la compilation du noyau (si je ne dis pas de bêtise, sur un FreeBSD, un make buildkernel sur des sources "propres" utilisera les versions installées de gcc et ses amis, tandis qu'après un buildworld il utilisera ceux fraîchement compilés.)
Après, toutes les mises à jour ne nécessite pas de re-compilation du monde. En gros, dans le cas des màj d'une release (RELENG_6_1 par exemple) /usr/src/UPDATING indique ce qui a été changé et les alertes de sécu indique s'il faut tout recompiler ou bien si juste la partie incriminée suffit. Dans le cas de -STABLE (RELENG_6), mieux toute recompiler, c'est plus simple. Idem pour CURRENT.
Pour finir, bien évidement tu peux recompiler le noyau sans le monde si tu n'as pas mis tes sources à jour, ça n'aura pas d'incidence.
