"KDE 4.3.2 est efficace et rapide. Ce n’est pas un environnement de
travail facile d’accès, car il est aussi puissant que polyvalent. Une
impression de fouillis se fait donc rapidement sentir. Les plus frileux
préféreront donc peut-être GNOME, qui est ici présent en mouture
2.28.1."
Essayez d'y comprendre qqchose ... En tout cas c'est pas fait pour
travailler...
"Un manque flagrant de sobriété
Une distribution Linux axée sur KDE est toujours intéressante.
Toutefois, la complexité de cet environnement de bureau empire à cause
des choix réalisés par Mandriva. Il est ainsi dommage qu’autant
d’applications KDE soient installées par défaut. Était-il nécessaire de
proposer plusieurs dizaines de jeux, ou des outils multiples effectuant
des tâches identiques ? Même constat avec le design de l’OS : il est
superbe, mais peu adapté aux professionnels. Heureusement, ce point
pourra facilement être corrigé"
Essayez d'y comprendre qqchose ... En tout cas c'est pas fait pour
travailler...
"Et que dire de l’excellente suite bureautique KOffice, qui n’est même
pas installée par défaut"
Essayez d'y comprendre qqchose ... En tout cas c'est pas fait pour
travailler...
Bref, c'est un jouet de boutonneux cliquodrômé
--
P4nd1-P4nd4 vous salue, et annonce que le petit ourson possède
désormais son blog
p4nd1-p4nd4.over-blog.com
Le Tue, 10 Nov 2009 12:14:59 +0000, Nicolas George a écrit :
Kevin Denis , dans le message , a écrit :
Cf ksplice.com; on peut patcher sans rebooter.
Si le noyau n'a pas été prévu pour dès le début de sa conception, ce genre de truc ne peut qu'être un bricolage à la stabilité douteuse.
Pour avoir eu l'occasion de discuter f2f avec le type à l'origine du projet, ksplice est tellement simple que ça ne peut que marcher. Ksplice, c'est surtout une idée lumineuse, techniquement ça n'est pas horriblement compliqué. Et ça permet de patcher ~ 90% du noyau.
-- mauve - http://13zenrv.fr dernier article : http://13zenrv.fr/2009/11/10/faut-il-sauver-rama-yade/
Le Tue, 10 Nov 2009 12:14:59 +0000, Nicolas George a écrit :
Kevin Denis , dans le message
<slrnhfiki6.i12.kevin@slackwall.local.tux>, a écrit :
Cf ksplice.com; on peut patcher sans rebooter.
Si le noyau n'a pas été prévu pour dès le début de sa conception, ce
genre de truc ne peut qu'être un bricolage à la stabilité douteuse.
Pour avoir eu l'occasion de discuter f2f avec le type à l'origine du
projet, ksplice est tellement simple que ça ne peut que marcher. Ksplice,
c'est surtout une idée lumineuse, techniquement ça n'est pas horriblement
compliqué. Et ça permet de patcher ~ 90% du noyau.
--
mauve - http://13zenrv.fr
dernier article :
http://13zenrv.fr/2009/11/10/faut-il-sauver-rama-yade/
Le Tue, 10 Nov 2009 12:14:59 +0000, Nicolas George a écrit :
Kevin Denis , dans le message , a écrit :
Cf ksplice.com; on peut patcher sans rebooter.
Si le noyau n'a pas été prévu pour dès le début de sa conception, ce genre de truc ne peut qu'être un bricolage à la stabilité douteuse.
Pour avoir eu l'occasion de discuter f2f avec le type à l'origine du projet, ksplice est tellement simple que ça ne peut que marcher. Ksplice, c'est surtout une idée lumineuse, techniquement ça n'est pas horriblement compliqué. Et ça permet de patcher ~ 90% du noyau.
-- mauve - http://13zenrv.fr dernier article : http://13zenrv.fr/2009/11/10/faut-il-sauver-rama-yade/
talon
mauve wrote:
Le Tue, 10 Nov 2009 12:14:59 +0000, Nicolas George a écrit :
> Kevin Denis , dans le message > , a écrit : >> Cf ksplice.com; on peut patcher sans rebooter. > > Si le noyau n'a pas été prévu pour dès le début de sa conception, ce > genre de truc ne peut qu'être un bricolage à la stabilité douteuse.
Pour avoir eu l'occasion de discuter f2f avec le type à l'origine du projet, ksplice est tellement simple que ça ne peut que marcher. Ksplice, c'est surtout une idée lumineuse, techniquement ça n'est pas horriblement compliqué. Et ça permet de patcher ~ 90% du noyau.
L'explication de ksplice elle est ici: http://www.ksplice.com/doc/ksplice.pdf
Je te recopie quelques points:
If the target patch does not make semantic changes, then no programming is necessary. Since kernel security patches and other important bug corrections are usually designed to change the software as little as possible, we can expect many of these patches to make no semantic changes to data structures. Our evaluation confirms this intuition for Linux security patches.
Donc déjà ici quelques hypothèses "radicales". Ensuite:
Ksplice performs replacements on entire functions; if any code within a function is modified by the patch, then Ksplice will replace the entire function. Ksplice replaces a function by linking a new version of the function, called the replace- ment code, into the kernel and by placing a jump instruction in the running kernel's memory, at the start of the obsolete function, to direct execution to the replacement code.
Autrement dit exactement ce que faisaient les debuggeurs binaires genre adb il y a des décennies. Si le patch concerne par exemple la gestion des tables de page, sur un noyau en activité, avec des tables déjà remplies il y a gros à parier qu'un OOPS va s'ensuivre rapidement. Plus généralement il est clair que l'on peut patcher comme ça le code du noyau, mais qu'arrive t'il aux structures de données du noyau?
--
Michel TALON
mauve <aucune@importance.invalid> wrote:
Le Tue, 10 Nov 2009 12:14:59 +0000, Nicolas George a écrit :
> Kevin Denis , dans le message
> <slrnhfiki6.i12.kevin@slackwall.local.tux>, a écrit :
>> Cf ksplice.com; on peut patcher sans rebooter.
>
> Si le noyau n'a pas été prévu pour dès le début de sa conception, ce
> genre de truc ne peut qu'être un bricolage à la stabilité douteuse.
Pour avoir eu l'occasion de discuter f2f avec le type à l'origine du
projet, ksplice est tellement simple que ça ne peut que marcher. Ksplice,
c'est surtout une idée lumineuse, techniquement ça n'est pas horriblement
compliqué. Et ça permet de patcher ~ 90% du noyau.
L'explication de ksplice elle est ici:
http://www.ksplice.com/doc/ksplice.pdf
Je te recopie quelques points:
If the target patch does not make semantic changes, then
no programming is necessary. Since kernel security patches
and other important bug corrections are usually designed
to change the software as little as possible, we can expect
many of these patches to make no semantic changes to data
structures. Our evaluation confirms this intuition for Linux
security patches.
Donc déjà ici quelques hypothèses "radicales". Ensuite:
Ksplice performs replacements on entire functions; if any
code within a function is modified by the patch, then Ksplice
will replace the entire function. Ksplice replaces a function
by linking a new version of the function, called the replace-
ment code, into the kernel and by placing a jump instruction
in the running kernel's memory, at the start of the obsolete
function, to direct execution to the replacement code.
Autrement dit exactement ce que faisaient les debuggeurs binaires genre
adb il y a des décennies. Si le patch concerne par exemple la gestion
des tables de page, sur un noyau en activité, avec des tables déjà
remplies il y a gros à parier qu'un OOPS va s'ensuivre rapidement.
Plus généralement il est clair que l'on peut patcher comme ça le code du
noyau, mais qu'arrive t'il aux structures de données du noyau?
Le Tue, 10 Nov 2009 12:14:59 +0000, Nicolas George a écrit :
> Kevin Denis , dans le message > , a écrit : >> Cf ksplice.com; on peut patcher sans rebooter. > > Si le noyau n'a pas été prévu pour dès le début de sa conception, ce > genre de truc ne peut qu'être un bricolage à la stabilité douteuse.
Pour avoir eu l'occasion de discuter f2f avec le type à l'origine du projet, ksplice est tellement simple que ça ne peut que marcher. Ksplice, c'est surtout une idée lumineuse, techniquement ça n'est pas horriblement compliqué. Et ça permet de patcher ~ 90% du noyau.
L'explication de ksplice elle est ici: http://www.ksplice.com/doc/ksplice.pdf
Je te recopie quelques points:
If the target patch does not make semantic changes, then no programming is necessary. Since kernel security patches and other important bug corrections are usually designed to change the software as little as possible, we can expect many of these patches to make no semantic changes to data structures. Our evaluation confirms this intuition for Linux security patches.
Donc déjà ici quelques hypothèses "radicales". Ensuite:
Ksplice performs replacements on entire functions; if any code within a function is modified by the patch, then Ksplice will replace the entire function. Ksplice replaces a function by linking a new version of the function, called the replace- ment code, into the kernel and by placing a jump instruction in the running kernel's memory, at the start of the obsolete function, to direct execution to the replacement code.
Autrement dit exactement ce que faisaient les debuggeurs binaires genre adb il y a des décennies. Si le patch concerne par exemple la gestion des tables de page, sur un noyau en activité, avec des tables déjà remplies il y a gros à parier qu'un OOPS va s'ensuivre rapidement. Plus généralement il est clair que l'on peut patcher comme ça le code du noyau, mais qu'arrive t'il aux structures de données du noyau?
--
Michel TALON
Patrice Karatchentzeff
(Michel Talon) a écrit :
Autrement dit exactement ce que faisaient les debuggeurs binaires genre adb il y a des décennies. Si le patch concerne par exemple la gestion des tables de page, sur un noyau en activité, avec des tables déjà remplies il y a gros à parier qu'un OOPS va s'ensuivre rapidement. Plus généralement il est clair que l'on peut patcher comme ça le code du noyau, mais qu'arrive t'il aux structures de données du noyau?
Ça m'étonnerait que cela n'effectue pas un gel total de la fonction (et donc un flush des données) avant de lancer le patch... sauf si le patch est compatible avec la récupération des données...
Autrement dit exactement ce que faisaient les debuggeurs binaires genre
adb il y a des décennies. Si le patch concerne par exemple la gestion
des tables de page, sur un noyau en activité, avec des tables déjà
remplies il y a gros à parier qu'un OOPS va s'ensuivre rapidement.
Plus généralement il est clair que l'on peut patcher comme ça le code du
noyau, mais qu'arrive t'il aux structures de données du noyau?
Ça m'étonnerait que cela n'effectue pas un gel total de la fonction
(et donc un flush des données) avant de lancer le patch... sauf si le
patch est compatible avec la récupération des données...
Autrement dit exactement ce que faisaient les debuggeurs binaires genre adb il y a des décennies. Si le patch concerne par exemple la gestion des tables de page, sur un noyau en activité, avec des tables déjà remplies il y a gros à parier qu'un OOPS va s'ensuivre rapidement. Plus généralement il est clair que l'on peut patcher comme ça le code du noyau, mais qu'arrive t'il aux structures de données du noyau?
Ça m'étonnerait que cela n'effectue pas un gel total de la fonction (et donc un flush des données) avant de lancer le patch... sauf si le patch est compatible avec la récupération des données...
Le Tue, 10 Nov 2009 15:41:26 +0000, Michel Talon a écrit :
mauve wrote:
Le Tue, 10 Nov 2009 12:14:59 +0000, Nicolas George a écrit :
> Kevin Denis , dans le message > , a écrit : >> Cf ksplice.com; on peut patcher sans rebooter. > > Si le noyau n'a pas été prévu pour dès le début de sa conception, ce > genre de truc ne peut qu'être un bricolage à la stabilité douteuse.
Pour avoir eu l'occasion de discuter f2f avec le type à l'origine du projet, ksplice est tellement simple que ça ne peut que marcher. Ksplice, c'est surtout une idée lumineuse, techniquement ça n'est pas horriblement compliqué. Et ça permet de patcher ~ 90% du noyau.
L'explication de ksplice elle est ici: http://www.ksplice.com/doc/ksplice.pdf
Je te recopie quelques points:
If the target patch does not make semantic changes, then no programming is necessary. Since kernel security patches and other important bug corrections are usually designed to change the software as little as possible, we can expect many of these patches to make no semantic changes to data structures. Our evaluation confirms this intuition for Linux security patches.
Donc déjà ici quelques hypothèses "radicales". Ensuite:
Ce sont des hypothèses qui ont été vérifiées quantitativement ; ksplice est le produit d'une thèse de fin d'étude du MIT, dans laquelle se trouvent les données brutes qui justifient statistiquement ce projet. Il n'est dit nulle part que c'est une solution 100% parfaite. C'est un outil de plus, parmi de nombreux autres, pour les administrateurs système, qui remplit un vide dans le but d'améliorer la sécurité globale.
Ksplice performs replacements on entire functions; if any code within a function is modified by the patch, then Ksplice will replace the entire function. Ksplice replaces a function by linking a new version of the function, called the replace- ment code, into the kernel and by placing a jump instruction in the running kernel's memory, at the start of the obsolete function, to direct execution to the replacement code.
Autrement dit exactement ce que faisaient les debuggeurs binaires genre adb il y a des décennies. Si le patch concerne par exemple la gestion des tables de page, sur un noyau en activité, avec des tables déjà remplies il y a gros à parier qu'un OOPS va s'ensuivre rapidement. Plus généralement il est clair que l'on peut patcher comme ça le code du noyau, mais qu'arrive t'il aux structures de données du noyau?
Tu te place exactement dans le cas qui n'est pas couvert par ksplice, et tu es de mauvaise foi puisque tu cite justement le passage des explications où c'est exposé.
Ksplice n'est pas destiné à sauver un uptime de 4 ans ; tant pis pour l'admin que ça fait b*der, ce n'est pas un concours. Ksplice est fait pour boucher un trou de sécurité le temps de programmer un cycle de maintenance / reboot. Et effectivement, ça fonctionne un peu comme adb, ou même comme un virus d'EXE sous MS-DOS.
Dans la pratique, quand un security advisory est corrigé par un patch, l'équipe de ksplice analyse le patch ; dans 80% des cas, ils n'ont rien à faire : ils collent le patch dans un stub. Dans 10 autres % des cas, ils adaptent le patch à leur stub. Ensuite, ils préviennent qu'un nouveau correctif ksplice est dispo. Les admins qui le souhaitent téléchargent ce patch, appliquent ksplice, et roule.
Si un patch touche les structures de données, ce qu'aucun patch de sécurité ne devrait faire, ils déclarent forfait, et on se retrouve dans la même situation que si ksplice n'existait pas.
Le but, c'est de tenir la machine en prod sans reboot le temps de rentrer dans un cycle de maintenance programmé, pour ne pas avoir à débrancher une ferme complète dans l'urgence, mais pouvoir effectuer une maintenance complète par roulement sans stress de se faire trouer pendant ce temps-là.
Une solution « good enough ».
-- mauve - http://13zenrv.fr dernier article : http://13zenrv.fr/2009/11/10/faut-il-sauver-rama-yade/
Le Tue, 10 Nov 2009 15:41:26 +0000, Michel Talon a écrit :
mauve <aucune@importance.invalid> wrote:
Le Tue, 10 Nov 2009 12:14:59 +0000, Nicolas George a écrit :
> Kevin Denis , dans le message
> <slrnhfiki6.i12.kevin@slackwall.local.tux>, a écrit :
>> Cf ksplice.com; on peut patcher sans rebooter.
>
> Si le noyau n'a pas été prévu pour dès le début de sa conception, ce
> genre de truc ne peut qu'être un bricolage à la stabilité douteuse.
Pour avoir eu l'occasion de discuter f2f avec le type à l'origine du
projet, ksplice est tellement simple que ça ne peut que marcher.
Ksplice, c'est surtout une idée lumineuse, techniquement ça n'est pas
horriblement compliqué. Et ça permet de patcher ~ 90% du noyau.
L'explication de ksplice elle est ici:
http://www.ksplice.com/doc/ksplice.pdf
Je te recopie quelques points:
If the target patch does not make semantic changes, then
no programming is necessary. Since kernel security patches and other
important bug corrections are usually designed to change the software as
little as possible, we can expect many of these patches to make no
semantic changes to data structures. Our evaluation confirms this
intuition for Linux security patches.
Donc déjà ici quelques hypothèses "radicales". Ensuite:
Ce sont des hypothèses qui ont été vérifiées quantitativement ; ksplice
est le produit d'une thèse de fin d'étude du MIT, dans laquelle se
trouvent les données brutes qui justifient statistiquement ce projet. Il
n'est dit nulle part que c'est une solution 100% parfaite. C'est un outil
de plus, parmi de nombreux autres, pour les administrateurs système, qui
remplit un vide dans le but d'améliorer la sécurité globale.
Ksplice performs replacements on entire functions; if any
code within a function is modified by the patch, then Ksplice will
replace the entire function. Ksplice replaces a function by linking a
new version of the function, called the replace- ment code, into the
kernel and by placing a jump instruction in the running kernel's memory,
at the start of the obsolete function, to direct execution to the
replacement code.
Autrement dit exactement ce que faisaient les debuggeurs binaires genre
adb il y a des décennies. Si le patch concerne par exemple la gestion
des tables de page, sur un noyau en activité, avec des tables déjà
remplies il y a gros à parier qu'un OOPS va s'ensuivre rapidement. Plus
généralement il est clair que l'on peut patcher comme ça le code du
noyau, mais qu'arrive t'il aux structures de données du noyau?
Tu te place exactement dans le cas qui n'est pas couvert par ksplice, et
tu es de mauvaise foi puisque tu cite justement le passage des
explications où c'est exposé.
Ksplice n'est pas destiné à sauver un uptime de 4 ans ; tant pis pour
l'admin que ça fait b*der, ce n'est pas un concours. Ksplice est fait
pour boucher un trou de sécurité le temps de programmer un cycle de
maintenance / reboot. Et effectivement, ça fonctionne un peu comme adb,
ou même comme un virus d'EXE sous MS-DOS.
Dans la pratique, quand un security advisory est corrigé par un patch,
l'équipe de ksplice analyse le patch ; dans 80% des cas, ils n'ont rien à
faire : ils collent le patch dans un stub. Dans 10 autres % des cas, ils
adaptent le patch à leur stub. Ensuite, ils préviennent qu'un nouveau
correctif ksplice est dispo. Les admins qui le souhaitent téléchargent ce
patch, appliquent ksplice, et roule.
Si un patch touche les structures de données, ce qu'aucun patch de
sécurité ne devrait faire, ils déclarent forfait, et on se retrouve dans
la même situation que si ksplice n'existait pas.
Le but, c'est de tenir la machine en prod sans reboot le temps de rentrer
dans un cycle de maintenance programmé, pour ne pas avoir à débrancher
une ferme complète dans l'urgence, mais pouvoir effectuer une maintenance
complète par roulement sans stress de se faire trouer pendant ce temps-là.
Une solution « good enough ».
--
mauve - http://13zenrv.fr
dernier article :
http://13zenrv.fr/2009/11/10/faut-il-sauver-rama-yade/
Le Tue, 10 Nov 2009 15:41:26 +0000, Michel Talon a écrit :
mauve wrote:
Le Tue, 10 Nov 2009 12:14:59 +0000, Nicolas George a écrit :
> Kevin Denis , dans le message > , a écrit : >> Cf ksplice.com; on peut patcher sans rebooter. > > Si le noyau n'a pas été prévu pour dès le début de sa conception, ce > genre de truc ne peut qu'être un bricolage à la stabilité douteuse.
Pour avoir eu l'occasion de discuter f2f avec le type à l'origine du projet, ksplice est tellement simple que ça ne peut que marcher. Ksplice, c'est surtout une idée lumineuse, techniquement ça n'est pas horriblement compliqué. Et ça permet de patcher ~ 90% du noyau.
L'explication de ksplice elle est ici: http://www.ksplice.com/doc/ksplice.pdf
Je te recopie quelques points:
If the target patch does not make semantic changes, then no programming is necessary. Since kernel security patches and other important bug corrections are usually designed to change the software as little as possible, we can expect many of these patches to make no semantic changes to data structures. Our evaluation confirms this intuition for Linux security patches.
Donc déjà ici quelques hypothèses "radicales". Ensuite:
Ce sont des hypothèses qui ont été vérifiées quantitativement ; ksplice est le produit d'une thèse de fin d'étude du MIT, dans laquelle se trouvent les données brutes qui justifient statistiquement ce projet. Il n'est dit nulle part que c'est une solution 100% parfaite. C'est un outil de plus, parmi de nombreux autres, pour les administrateurs système, qui remplit un vide dans le but d'améliorer la sécurité globale.
Ksplice performs replacements on entire functions; if any code within a function is modified by the patch, then Ksplice will replace the entire function. Ksplice replaces a function by linking a new version of the function, called the replace- ment code, into the kernel and by placing a jump instruction in the running kernel's memory, at the start of the obsolete function, to direct execution to the replacement code.
Autrement dit exactement ce que faisaient les debuggeurs binaires genre adb il y a des décennies. Si le patch concerne par exemple la gestion des tables de page, sur un noyau en activité, avec des tables déjà remplies il y a gros à parier qu'un OOPS va s'ensuivre rapidement. Plus généralement il est clair que l'on peut patcher comme ça le code du noyau, mais qu'arrive t'il aux structures de données du noyau?
Tu te place exactement dans le cas qui n'est pas couvert par ksplice, et tu es de mauvaise foi puisque tu cite justement le passage des explications où c'est exposé.
Ksplice n'est pas destiné à sauver un uptime de 4 ans ; tant pis pour l'admin que ça fait b*der, ce n'est pas un concours. Ksplice est fait pour boucher un trou de sécurité le temps de programmer un cycle de maintenance / reboot. Et effectivement, ça fonctionne un peu comme adb, ou même comme un virus d'EXE sous MS-DOS.
Dans la pratique, quand un security advisory est corrigé par un patch, l'équipe de ksplice analyse le patch ; dans 80% des cas, ils n'ont rien à faire : ils collent le patch dans un stub. Dans 10 autres % des cas, ils adaptent le patch à leur stub. Ensuite, ils préviennent qu'un nouveau correctif ksplice est dispo. Les admins qui le souhaitent téléchargent ce patch, appliquent ksplice, et roule.
Si un patch touche les structures de données, ce qu'aucun patch de sécurité ne devrait faire, ils déclarent forfait, et on se retrouve dans la même situation que si ksplice n'existait pas.
Le but, c'est de tenir la machine en prod sans reboot le temps de rentrer dans un cycle de maintenance programmé, pour ne pas avoir à débrancher une ferme complète dans l'urgence, mais pouvoir effectuer une maintenance complète par roulement sans stress de se faire trouer pendant ce temps-là.
Une solution « good enough ».
-- mauve - http://13zenrv.fr dernier article : http://13zenrv.fr/2009/11/10/faut-il-sauver-rama-yade/
debug this fifo
Michel Talon wrote:
by linking a new version of the function, called the replace- ment code, into the kernel and by placing a jump instruction in the running kernel's memory, at the start of the obsolete function, to direct execution to the replacement code.
omg! superzap is alive!
Michel Talon wrote:
by linking a new version of the function, called the replace-
ment code, into the kernel and by placing a jump instruction
in the running kernel's memory, at the start of the obsolete
function, to direct execution to the replacement code.
by linking a new version of the function, called the replace- ment code, into the kernel and by placing a jump instruction in the running kernel's memory, at the start of the obsolete function, to direct execution to the replacement code.
omg! superzap is alive!
talon
mauve wrote:
Tu te place exactement dans le cas qui n'est pas couvert par ksplice, et tu es de mauvaise foi puisque tu cite justement le passage des explications où c'est exposé.
Donc grosso modo on ne doit pas être loin de ce que je disais, un truc qui permet de patcher toutes les parties non essentielles du noyau, mais pas la gestion de mémoire et des processus, ce qui me semblait raisonnable. Le reste est en fait en grande partie couvert par des modules, donc on pourrait envisager de retirer le module (ce qui prend soin de la mise à zéro des structures de données correspondantes) et réinstaller une version patchée. Si on doit patcher la couche réseau je me demande ce qui se passe, il doit falloir probablement l'arrêter.
--
Michel TALON
mauve <aucune@importance.invalid> wrote:
Tu te place exactement dans le cas qui n'est pas couvert par ksplice, et
tu es de mauvaise foi puisque tu cite justement le passage des
explications où c'est exposé.
Donc grosso modo on ne doit pas être loin de ce que je disais, un truc
qui permet de patcher toutes les parties non essentielles du noyau, mais
pas la gestion de mémoire et des processus, ce qui me semblait
raisonnable. Le reste est en fait en grande partie couvert par des
modules, donc on pourrait envisager de retirer le module (ce qui prend
soin de la mise à zéro des structures de données correspondantes) et
réinstaller une version patchée. Si on doit patcher la couche réseau je
me demande ce qui se passe, il doit falloir probablement l'arrêter.
Tu te place exactement dans le cas qui n'est pas couvert par ksplice, et tu es de mauvaise foi puisque tu cite justement le passage des explications où c'est exposé.
Donc grosso modo on ne doit pas être loin de ce que je disais, un truc qui permet de patcher toutes les parties non essentielles du noyau, mais pas la gestion de mémoire et des processus, ce qui me semblait raisonnable. Le reste est en fait en grande partie couvert par des modules, donc on pourrait envisager de retirer le module (ce qui prend soin de la mise à zéro des structures de données correspondantes) et réinstaller une version patchée. Si on doit patcher la couche réseau je me demande ce qui se passe, il doit falloir probablement l'arrêter.
Mes propres emails passent par un Qmail, j'en recois plus de 600 par jour et en envoie un bonne cinquantaine vraiment partout a travers le monde et je n'ai jamais eu le probleme que tu decris la.
Mes propres emails passent par un Qmail, j'en recois plus de 600 par
jour et en envoie un bonne cinquantaine vraiment partout a travers le
monde et je n'ai jamais eu le probleme que tu decris la.
Mes propres emails passent par un Qmail, j'en recois plus de 600 par jour et en envoie un bonne cinquantaine vraiment partout a travers le monde et je n'ai jamais eu le probleme que tu decris la.
Les admins systemes sont des ouvriers qui ont en charge de faire marcher un service pour des clients.
Des ouvriers ? Ma foi, pourquoi pas !
-- Jacques.
Julien BLACHE
Patrice Karatchentzeff wrote:
Tu m'inquiètes. J'ai des debian partout et je n'ai jamais vu ça. Tu n'aurais pas par hasard la fameuse ligne allow-hotplug ? Je n'ai jamais vu un tel comportement et je me tape toutes mes configurations en ligne de commande...
Il doit avoir cette (censuré) de gnome-network-manager qui lui fait des misères.
Sur un serveur, ça m'étonnerait, mais ça ressemble à une dauberie du genre.
En tout cas, pareil que JKB, jamais vu ça.
JB.
-- BOFH excuse #379: We've picked COBOL as the language of choice.
Tu m'inquiètes. J'ai des debian partout et je n'ai jamais vu
ça. Tu n'aurais pas par hasard la fameuse ligne allow-hotplug
? Je n'ai jamais vu un tel comportement et je me tape toutes
mes configurations en ligne de commande...
Il doit avoir cette (censuré) de gnome-network-manager qui lui fait
des misères.
Sur un serveur, ça m'étonnerait, mais ça ressemble à une dauberie du
genre.
En tout cas, pareil que JKB, jamais vu ça.
JB.
--
BOFH excuse #379:
We've picked COBOL as the language of choice.
Tu m'inquiètes. J'ai des debian partout et je n'ai jamais vu ça. Tu n'aurais pas par hasard la fameuse ligne allow-hotplug ? Je n'ai jamais vu un tel comportement et je me tape toutes mes configurations en ligne de commande...
Il doit avoir cette (censuré) de gnome-network-manager qui lui fait des misères.
Sur un serveur, ça m'étonnerait, mais ça ressemble à une dauberie du genre.
En tout cas, pareil que JKB, jamais vu ça.
JB.
-- BOFH excuse #379: We've picked COBOL as the language of choice.
Emmanuel Florac
Le Tue, 10 Nov 2009 08:03:28 +0000, JKB a écrit:
Ouaips, enfin, personnellement, j'ai des souvenirs émus de bootstrap de Convex et pour rien au monde je ne retoucherai un panneau de clefs. On peut faire largement plus efficace avec un processeur de service.
Ce qui ne te tues pas te rends plus fort, comme disait l'autre.
-- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. C.A.R. Hoare.
Le Tue, 10 Nov 2009 08:03:28 +0000, JKB a écrit:
Ouaips, enfin, personnellement, j'ai des souvenirs émus de bootstrap
de Convex et pour rien au monde je ne retoucherai un panneau de clefs.
On peut faire largement plus efficace avec un processeur de service.
Ce qui ne te tues pas te rends plus fort, comme disait l'autre.
--
There are two ways of constructing a software design: One way is to make
it so simple that there are obviously no deficiencies, and the other way
is to make it so complicated that there are no obvious deficiencies. The
first method is far more difficult.
C.A.R. Hoare.
Ouaips, enfin, personnellement, j'ai des souvenirs émus de bootstrap de Convex et pour rien au monde je ne retoucherai un panneau de clefs. On peut faire largement plus efficace avec un processeur de service.
Ce qui ne te tues pas te rends plus fort, comme disait l'autre.
-- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. C.A.R. Hoare.
Emmanuel Florac
Le Tue, 10 Nov 2009 19:00:56 +0100, Julien BLACHE a écrit:
Sur un serveur, ça m'étonnerait, mais ça ressemble à une dauberie du genre.
En tout cas, pareil que JKB, jamais vu ça.
J'espère que vous dites vrai, malheureusement j'ai énormément manqué de temps ce qui fait que je suis toujours bloqué sous etch...
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Le Tue, 10 Nov 2009 19:00:56 +0100, Julien BLACHE a écrit:
Sur un serveur, ça m'étonnerait, mais ça ressemble à une dauberie du
genre.
En tout cas, pareil que JKB, jamais vu ça.
J'espère que vous dites vrai, malheureusement j'ai énormément manqué de
temps ce qui fait que je suis toujours bloqué sous etch...
--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray
