Le 14/05/13 03:35, william a écrit :On 2013-05-13, Pe Hache wrote:Même sur mon Lenovo perso, qui a pourtant une communauté d'utilisateurs
Linux assez large et donc des retours de bugs permettant de faire
progresser le truc, tout n'est pas top (et j'ai pou comparer à Windows
puisqu'avant je l'avais sous Windows):
- par défaut Ubuntu installe un pilote de touchpad très basique. On peut en
installer un autre un peu plus complet (à condition de savoir qu'il
existe), mais on est encore loin de la richesse de l'utilitaire Lenovo
installé par défaut sous Windows.
ha ?
Oui
- les touches de fonction marchottent, mais pas aussi bien que sous Windows
Pas de soucis de mapping.
T430, debian jessie
Comme quoi chaque combinaison OS/machine est un cas particulier, et rien
ne remplace la mise au point par le fabriquant lui-même.
Mais au delà du pur mapping (je dois avoir 2 ou 3 touches qui ne
fonctionnent pas), c'est aussi un problème de comportement : par exemple
l'appui sur les touche de luminosité ne se traduit que par 2 ou 3
paliers différents, contre une dizaine sous Windows. Ou encore, l'appui
sur les touches de volume ne donne aucun feedback à l'écran sur où on en
est.
- la gestion de la batterie est moins fine
J'utilise en mode connecté au secteur mais je ne vois pas trop de quel
problème il peut y avoir
Ben si tu voyais l'utilitaire Lenovo pour la gestion de la batterie sous
Windows, tu verrais mieux :-)
Le 14/05/13 03:35, william a écrit :
On 2013-05-13, Pe Hache <pehache.7@gmail.com> wrote:
Même sur mon Lenovo perso, qui a pourtant une communauté d'utilisateurs
Linux assez large et donc des retours de bugs permettant de faire
progresser le truc, tout n'est pas top (et j'ai pou comparer à Windows
puisqu'avant je l'avais sous Windows):
- par défaut Ubuntu installe un pilote de touchpad très basique. On peut en
installer un autre un peu plus complet (à condition de savoir qu'il
existe), mais on est encore loin de la richesse de l'utilitaire Lenovo
installé par défaut sous Windows.
ha ?
Oui
- les touches de fonction marchottent, mais pas aussi bien que sous Windows
Pas de soucis de mapping.
T430, debian jessie
Comme quoi chaque combinaison OS/machine est un cas particulier, et rien
ne remplace la mise au point par le fabriquant lui-même.
Mais au delà du pur mapping (je dois avoir 2 ou 3 touches qui ne
fonctionnent pas), c'est aussi un problème de comportement : par exemple
l'appui sur les touche de luminosité ne se traduit que par 2 ou 3
paliers différents, contre une dizaine sous Windows. Ou encore, l'appui
sur les touches de volume ne donne aucun feedback à l'écran sur où on en
est.
- la gestion de la batterie est moins fine
J'utilise en mode connecté au secteur mais je ne vois pas trop de quel
problème il peut y avoir
Ben si tu voyais l'utilitaire Lenovo pour la gestion de la batterie sous
Windows, tu verrais mieux :-)
Le 14/05/13 03:35, william a écrit :On 2013-05-13, Pe Hache wrote:Même sur mon Lenovo perso, qui a pourtant une communauté d'utilisateurs
Linux assez large et donc des retours de bugs permettant de faire
progresser le truc, tout n'est pas top (et j'ai pou comparer à Windows
puisqu'avant je l'avais sous Windows):
- par défaut Ubuntu installe un pilote de touchpad très basique. On peut en
installer un autre un peu plus complet (à condition de savoir qu'il
existe), mais on est encore loin de la richesse de l'utilitaire Lenovo
installé par défaut sous Windows.
ha ?
Oui
- les touches de fonction marchottent, mais pas aussi bien que sous Windows
Pas de soucis de mapping.
T430, debian jessie
Comme quoi chaque combinaison OS/machine est un cas particulier, et rien
ne remplace la mise au point par le fabriquant lui-même.
Mais au delà du pur mapping (je dois avoir 2 ou 3 touches qui ne
fonctionnent pas), c'est aussi un problème de comportement : par exemple
l'appui sur les touche de luminosité ne se traduit que par 2 ou 3
paliers différents, contre une dizaine sous Windows. Ou encore, l'appui
sur les touches de volume ne donne aucun feedback à l'écran sur où on en
est.
- la gestion de la batterie est moins fine
J'utilise en mode connecté au secteur mais je ne vois pas trop de quel
problème il peut y avoir
Ben si tu voyais l'utilitaire Lenovo pour la gestion de la batterie sous
Windows, tu verrais mieux :-)
On 2013-05-14, JKB wrote:Le 14 May 2013 01:34:57 GMT, william écrivait :ben si X, plante est ce que la machine plante (quelque soit le wm ?)
Très honnêtement, j'ai très rarement vu un serveur X planter. En
revanche, je ne puis pas en dire autant des différents WM.
Quelle est la différence ?
On 2013-05-14, JKB <jkb@koenigsberg.invalid> wrote:
Le 14 May 2013 01:34:57 GMT, william <blop@no.spam> écrivait :
ben si X, plante est ce que la machine plante (quelque soit le wm ?)
Très honnêtement, j'ai très rarement vu un serveur X planter. En
revanche, je ne puis pas en dire autant des différents WM.
Quelle est la différence ?
On 2013-05-14, JKB wrote:Le 14 May 2013 01:34:57 GMT, william écrivait :ben si X, plante est ce que la machine plante (quelque soit le wm ?)
Très honnêtement, j'ai très rarement vu un serveur X planter. En
revanche, je ne puis pas en dire autant des différents WM.
Quelle est la différence ?
>
> oue, mais dans des conditions biens particulières ou je poussais le
> bouchon un peu loin, et je bosse avec softimage 3D depuis 1992, sous
> SGI/irix, pc windows et linux, et sous toutes ces machines et systemes,
> j ai eu des plantages, donc il n existe pas de solution parfaite.
> quelque soit le sytème et la machine, quant on lui en fout pleins la
> gueule ca arrive que ca plante !
>
> une machine instable c'est une machine dont on ne peux rien faire, ce
> qui n'a rien a voir avec une machine qui crash quant on lui en fout
> plein les dents !
Donc pour toi, une machine métastable est stable. C'est beau, la
lobotomie microsoftienne. Pour moi, une machine stable, c'est un VAX
qui s'en prend plein la tronche durant onze ans et que tu éteins un
jour de déménagement en ayant complètement oublié qu'il était
encore utilisée.
Une machine qui se vautre grâce à une application userland n'est pas
stable.
>
> oue, mais dans des conditions biens particulières ou je poussais le
> bouchon un peu loin, et je bosse avec softimage 3D depuis 1992, sous
> SGI/irix, pc windows et linux, et sous toutes ces machines et systemes,
> j ai eu des plantages, donc il n existe pas de solution parfaite.
> quelque soit le sytème et la machine, quant on lui en fout pleins la
> gueule ca arrive que ca plante !
>
> une machine instable c'est une machine dont on ne peux rien faire, ce
> qui n'a rien a voir avec une machine qui crash quant on lui en fout
> plein les dents !
Donc pour toi, une machine métastable est stable. C'est beau, la
lobotomie microsoftienne. Pour moi, une machine stable, c'est un VAX
qui s'en prend plein la tronche durant onze ans et que tu éteins un
jour de déménagement en ayant complètement oublié qu'il était
encore utilisée.
Une machine qui se vautre grâce à une application userland n'est pas
stable.
>
> oue, mais dans des conditions biens particulières ou je poussais le
> bouchon un peu loin, et je bosse avec softimage 3D depuis 1992, sous
> SGI/irix, pc windows et linux, et sous toutes ces machines et systemes,
> j ai eu des plantages, donc il n existe pas de solution parfaite.
> quelque soit le sytème et la machine, quant on lui en fout pleins la
> gueule ca arrive que ca plante !
>
> une machine instable c'est une machine dont on ne peux rien faire, ce
> qui n'a rien a voir avec une machine qui crash quant on lui en fout
> plein les dents !
Donc pour toi, une machine métastable est stable. C'est beau, la
lobotomie microsoftienne. Pour moi, une machine stable, c'est un VAX
qui s'en prend plein la tronche durant onze ans et que tu éteins un
jour de déménagement en ayant complètement oublié qu'il était
encore utilisée.
Une machine qui se vautre grâce à une application userland n'est pas
stable.
Le lundi 13 mai 2013 19:49:45 UTC+2, JKB a écrit :
>
> oue, mais dans des conditions biens particulières ou je poussais le
> bouchon un peu loin, et je bosse avec softimage 3D depuis 1992, sous
> SGI/irix, pc windows et linux, et sous toutes ces machines et systemes,
> j ai eu des plantages, donc il n existe pas de solution parfaite.
> quelque soit le sytème et la machine, quant on lui en fout pleins la
> gueule ca arrive que ca plante !
>
> une machine instable c'est une machine dont on ne peux rien faire, ce
> qui n'a rien a voir avec une machine qui crash quant on lui en fout
> plein les dents !
Donc pour toi, une machine métastable est stable. C'est beau, la
lobotomie microsoftienne. Pour moi, une machine stable, c'est un VAX
qui s'en prend plein la tronche durant onze ans et que tu éteins un
jour de déménagement en ayant complètement oublié qu'il était
encore utilisée.
Une machine qui se vautre grâce à une application userland n'est pas
stable.
Je n'en sais rien pour VMS, mais tu peux faire planter à peu près n'importe unix avec des applications pathologiques en userland, si l'administrateur ne l'a l'a pas blindé de tous les côtés.
Je me souviens m'être fait remarquer et souffler dans les bronches en bloquant totalement le Mini (je ne sais plus de quel fabriquant) de mon école d'ingénieur, qui a fini par planter et rebooter. Je faisais mumuse avec le C que je venais de découvrir, à grand coup de fork() dans tous les sens, sauf que personne (même pas moi) ne pouvait arrêter les process que j'avais lancés :-)
Après, le concept de stabilité est tout à fait relatif aux besoins que tu as. Sachant que l'instabilité est la contrepartie de l'évolution rapide des fonctionnalités, tu peux accepter des plantages très épisodiques dans des conditions borderline, si ça signifie juste reprendre ton travail là où tu en étais 5mn avant, alors qu'un plantage est évidemment inenvisageable sur l'ordinateur de bord de la navette spatiale. Donc bon, un uptime de 11 ans sur une station de travail c'est les exploits de l'inutile.
Le lundi 13 mai 2013 19:49:45 UTC+2, JKB a écrit :
>
> oue, mais dans des conditions biens particulières ou je poussais le
> bouchon un peu loin, et je bosse avec softimage 3D depuis 1992, sous
> SGI/irix, pc windows et linux, et sous toutes ces machines et systemes,
> j ai eu des plantages, donc il n existe pas de solution parfaite.
> quelque soit le sytème et la machine, quant on lui en fout pleins la
> gueule ca arrive que ca plante !
>
> une machine instable c'est une machine dont on ne peux rien faire, ce
> qui n'a rien a voir avec une machine qui crash quant on lui en fout
> plein les dents !
Donc pour toi, une machine métastable est stable. C'est beau, la
lobotomie microsoftienne. Pour moi, une machine stable, c'est un VAX
qui s'en prend plein la tronche durant onze ans et que tu éteins un
jour de déménagement en ayant complètement oublié qu'il était
encore utilisée.
Une machine qui se vautre grâce à une application userland n'est pas
stable.
Je n'en sais rien pour VMS, mais tu peux faire planter à peu près n'importe unix avec des applications pathologiques en userland, si l'administrateur ne l'a l'a pas blindé de tous les côtés.
Je me souviens m'être fait remarquer et souffler dans les bronches en bloquant totalement le Mini (je ne sais plus de quel fabriquant) de mon école d'ingénieur, qui a fini par planter et rebooter. Je faisais mumuse avec le C que je venais de découvrir, à grand coup de fork() dans tous les sens, sauf que personne (même pas moi) ne pouvait arrêter les process que j'avais lancés :-)
Après, le concept de stabilité est tout à fait relatif aux besoins que tu as. Sachant que l'instabilité est la contrepartie de l'évolution rapide des fonctionnalités, tu peux accepter des plantages très épisodiques dans des conditions borderline, si ça signifie juste reprendre ton travail là où tu en étais 5mn avant, alors qu'un plantage est évidemment inenvisageable sur l'ordinateur de bord de la navette spatiale. Donc bon, un uptime de 11 ans sur une station de travail c'est les exploits de l'inutile.
Le lundi 13 mai 2013 19:49:45 UTC+2, JKB a écrit :
>
> oue, mais dans des conditions biens particulières ou je poussais le
> bouchon un peu loin, et je bosse avec softimage 3D depuis 1992, sous
> SGI/irix, pc windows et linux, et sous toutes ces machines et systemes,
> j ai eu des plantages, donc il n existe pas de solution parfaite.
> quelque soit le sytème et la machine, quant on lui en fout pleins la
> gueule ca arrive que ca plante !
>
> une machine instable c'est une machine dont on ne peux rien faire, ce
> qui n'a rien a voir avec une machine qui crash quant on lui en fout
> plein les dents !
Donc pour toi, une machine métastable est stable. C'est beau, la
lobotomie microsoftienne. Pour moi, une machine stable, c'est un VAX
qui s'en prend plein la tronche durant onze ans et que tu éteins un
jour de déménagement en ayant complètement oublié qu'il était
encore utilisée.
Une machine qui se vautre grâce à une application userland n'est pas
stable.
Je n'en sais rien pour VMS, mais tu peux faire planter à peu près n'importe unix avec des applications pathologiques en userland, si l'administrateur ne l'a l'a pas blindé de tous les côtés.
Je me souviens m'être fait remarquer et souffler dans les bronches en bloquant totalement le Mini (je ne sais plus de quel fabriquant) de mon école d'ingénieur, qui a fini par planter et rebooter. Je faisais mumuse avec le C que je venais de découvrir, à grand coup de fork() dans tous les sens, sauf que personne (même pas moi) ne pouvait arrêter les process que j'avais lancés :-)
Après, le concept de stabilité est tout à fait relatif aux besoins que tu as. Sachant que l'instabilité est la contrepartie de l'évolution rapide des fonctionnalités, tu peux accepter des plantages très épisodiques dans des conditions borderline, si ça signifie juste reprendre ton travail là où tu en étais 5mn avant, alors qu'un plantage est évidemment inenvisageable sur l'ordinateur de bord de la navette spatiale. Donc bon, un uptime de 11 ans sur une station de travail c'est les exploits de l'inutile.
>
> Je n'en sais rien pour VMS, mais tu peux faire planter
> à peu près n'importe unix avec des applications
> pathologiques en userland, si l'administrateur ne l'a
> l'a pas blindé de tous les côtés.
Non.
Si une application userland plante le noyau (qui ne tourne pas
dans le même espace mémoire), c'est que ton noyau a un gros
problème.
> Je me souviens m'être fait remarquer et souffler dans les
> bronches en bloquant totalement le Mini (je ne sais plus
> de quel fabriquant) de mon école d'ingénieur, qui a fini
> par planter et rebooter. Je faisais mumuse avec le C que
> je venais de découvrir, à grand coup de fork() dans tous
> les sens, sauf que personne (même pas moi) ne pouvait
> arrêter les process que j'avais lancés :-)
Ce n'est pas un plantage du noyau, c'est que le noyau n'a plus le
temps de traiter ce qu'on lui demande de traiter (et au passage,
c'est un problème de conception de ce noyau et de mauvaise gestion
des ressources).
Et ce genre de chose, tu peux le faire allègrement
sur certains Unix, Linux compris (en revanche, sur un NetBSD, tu risques
fort de te prendre un coup de pied aux fesses avec un message du type
'cannot fork'. Idem sous OpenBSD.). Ça ne plantera pas le noyau, ça
rendra la machine tellement lente qu'on la rebootera pour s'en
sortir.
> Après, le concept de stabilité est tout à fait relatif aux
> besoins que tu as. Sachant que l'instabilité est la
> contrepartie de l'évolution rapide des fonctionnalités,
> tu peux accepter des plantages très épisodiques dans des
> conditions borderline, si ça signifie juste reprendre ton travail
> là où tu en étais 5mn avant, alors qu'un plantage est évidemmen t
> inenvisageable sur l'ordinateur de bord de la navette spatiale.
> Donc bon, un uptime de 11 ans sur une station de travail c'est
> les exploits de l'inutile.
Je ne t'ai pas parlé de station de travail.
Quant à l'évolution des
fonctionnalités, elle ne justifie pas l'instabilité.
Mais il est
vrai que l'idéal du progrès a été remplacé par l'idéal de
l'innovation. Il ne s'agit pas que cela fonctionne mieux, mais que
cela soit nouveau, même si le fonctionnement est pire qu'avant.
Personnellement, je n'accepte pas un plantage d'une machine sur
autre chose qu'un problème matériel. Mais c'est mon côté dinosau re avec
des écailles.
>
> Je n'en sais rien pour VMS, mais tu peux faire planter
> à peu près n'importe unix avec des applications
> pathologiques en userland, si l'administrateur ne l'a
> l'a pas blindé de tous les côtés.
Non.
Si une application userland plante le noyau (qui ne tourne pas
dans le même espace mémoire), c'est que ton noyau a un gros
problème.
> Je me souviens m'être fait remarquer et souffler dans les
> bronches en bloquant totalement le Mini (je ne sais plus
> de quel fabriquant) de mon école d'ingénieur, qui a fini
> par planter et rebooter. Je faisais mumuse avec le C que
> je venais de découvrir, à grand coup de fork() dans tous
> les sens, sauf que personne (même pas moi) ne pouvait
> arrêter les process que j'avais lancés :-)
Ce n'est pas un plantage du noyau, c'est que le noyau n'a plus le
temps de traiter ce qu'on lui demande de traiter (et au passage,
c'est un problème de conception de ce noyau et de mauvaise gestion
des ressources).
Et ce genre de chose, tu peux le faire allègrement
sur certains Unix, Linux compris (en revanche, sur un NetBSD, tu risques
fort de te prendre un coup de pied aux fesses avec un message du type
'cannot fork'. Idem sous OpenBSD.). Ça ne plantera pas le noyau, ça
rendra la machine tellement lente qu'on la rebootera pour s'en
sortir.
> Après, le concept de stabilité est tout à fait relatif aux
> besoins que tu as. Sachant que l'instabilité est la
> contrepartie de l'évolution rapide des fonctionnalités,
> tu peux accepter des plantages très épisodiques dans des
> conditions borderline, si ça signifie juste reprendre ton travail
> là où tu en étais 5mn avant, alors qu'un plantage est évidemmen t
> inenvisageable sur l'ordinateur de bord de la navette spatiale.
> Donc bon, un uptime de 11 ans sur une station de travail c'est
> les exploits de l'inutile.
Je ne t'ai pas parlé de station de travail.
Quant à l'évolution des
fonctionnalités, elle ne justifie pas l'instabilité.
Mais il est
vrai que l'idéal du progrès a été remplacé par l'idéal de
l'innovation. Il ne s'agit pas que cela fonctionne mieux, mais que
cela soit nouveau, même si le fonctionnement est pire qu'avant.
Personnellement, je n'accepte pas un plantage d'une machine sur
autre chose qu'un problème matériel. Mais c'est mon côté dinosau re avec
des écailles.
>
> Je n'en sais rien pour VMS, mais tu peux faire planter
> à peu près n'importe unix avec des applications
> pathologiques en userland, si l'administrateur ne l'a
> l'a pas blindé de tous les côtés.
Non.
Si une application userland plante le noyau (qui ne tourne pas
dans le même espace mémoire), c'est que ton noyau a un gros
problème.
> Je me souviens m'être fait remarquer et souffler dans les
> bronches en bloquant totalement le Mini (je ne sais plus
> de quel fabriquant) de mon école d'ingénieur, qui a fini
> par planter et rebooter. Je faisais mumuse avec le C que
> je venais de découvrir, à grand coup de fork() dans tous
> les sens, sauf que personne (même pas moi) ne pouvait
> arrêter les process que j'avais lancés :-)
Ce n'est pas un plantage du noyau, c'est que le noyau n'a plus le
temps de traiter ce qu'on lui demande de traiter (et au passage,
c'est un problème de conception de ce noyau et de mauvaise gestion
des ressources).
Et ce genre de chose, tu peux le faire allègrement
sur certains Unix, Linux compris (en revanche, sur un NetBSD, tu risques
fort de te prendre un coup de pied aux fesses avec un message du type
'cannot fork'. Idem sous OpenBSD.). Ça ne plantera pas le noyau, ça
rendra la machine tellement lente qu'on la rebootera pour s'en
sortir.
> Après, le concept de stabilité est tout à fait relatif aux
> besoins que tu as. Sachant que l'instabilité est la
> contrepartie de l'évolution rapide des fonctionnalités,
> tu peux accepter des plantages très épisodiques dans des
> conditions borderline, si ça signifie juste reprendre ton travail
> là où tu en étais 5mn avant, alors qu'un plantage est évidemmen t
> inenvisageable sur l'ordinateur de bord de la navette spatiale.
> Donc bon, un uptime de 11 ans sur une station de travail c'est
> les exploits de l'inutile.
Je ne t'ai pas parlé de station de travail.
Quant à l'évolution des
fonctionnalités, elle ne justifie pas l'instabilité.
Mais il est
vrai que l'idéal du progrès a été remplacé par l'idéal de
l'innovation. Il ne s'agit pas que cela fonctionne mieux, mais que
cela soit nouveau, même si le fonctionnement est pire qu'avant.
Personnellement, je n'accepte pas un plantage d'une machine sur
autre chose qu'un problème matériel. Mais c'est mon côté dinosau re avec
des écailles.
Le mardi 14 mai 2013 11:12:16 UTC+2, JKB a écrit :
>
> Je n'en sais rien pour VMS, mais tu peux faire planter
> à peu près n'importe unix avec des applications
> pathologiques en userland, si l'administrateur ne l'a
> l'a pas blindé de tous les côtés.
Non.
Si
Si une application userland plante le noyau (qui ne tourne pas
dans le même espace mémoire), c'est que ton noyau a un gros
problème.
C'est marrant comme tu changes les termes du problème
au cours de la discussion. Jusqu'à maintenant on parlait du
plantage de la machine, quelle qu'en soit la raison.
> Je me souviens m'être fait remarquer et souffler dans les
> bronches en bloquant totalement le Mini (je ne sais plus
> de quel fabriquant) de mon école d'ingénieur, qui a fini
> par planter et rebooter. Je faisais mumuse avec le C que
> je venais de découvrir, à grand coup de fork() dans tous
> les sens, sauf que personne (même pas moi) ne pouvait
> arrêter les process que j'avais lancés :-)
Ce n'est pas un plantage du noyau, c'est que le noyau n'a plus le
temps de traiter ce qu'on lui demande de traiter (et au passage,
c'est un problème de conception de ce noyau et de mauvaise gestion
des ressources).
Et ce genre de chose, tu peux le faire allègrement
sur certains Unix, Linux compris (en revanche, sur un NetBSD, tu risques
fort de te prendre un coup de pied aux fesses avec un message du type
'cannot fork'. Idem sous OpenBSD.). Ça ne plantera pas le noyau, ça
rendra la machine tellement lente qu'on la rebootera pour s'en
sortir.
On s'en fout, le résultat final est le même : la machine
doit être rebootée.
Quant à l'évolution des
fonctionnalités, elle ne justifie pas l'instabilité.
Ca explique, je n'ai pas dit que ça justifiait.Mais il est
vrai que l'idéal du progrès a été remplacé par l'idéal de
l'innovation. Il ne s'agit pas que cela fonctionne mieux, mais que
cela soit nouveau, même si le fonctionnement est pire qu'avant.
Si ça apporte par ailleurs des fonctionnalités utiles, le bilan n'est pas forcément négatif, sachant que ce qui est temporairement dégradé peut être corrigé par la suite. Encore une fois tout dépend de l'usage.
Personnellement, je n'accepte pas un plantage d'une machine sur
autre chose qu'un problème matériel. Mais c'est mon côté dinosaure avec
des écailles.
Les dinosaures ont disparu faute d'avoir pu s'adapter : fait gaffe !
A part ça, je crois que ton killfile a encore planté : des
problèmes de stabilité ?
Le mardi 14 mai 2013 11:12:16 UTC+2, JKB a écrit :
>
> Je n'en sais rien pour VMS, mais tu peux faire planter
> à peu près n'importe unix avec des applications
> pathologiques en userland, si l'administrateur ne l'a
> l'a pas blindé de tous les côtés.
Non.
Si
Si une application userland plante le noyau (qui ne tourne pas
dans le même espace mémoire), c'est que ton noyau a un gros
problème.
C'est marrant comme tu changes les termes du problème
au cours de la discussion. Jusqu'à maintenant on parlait du
plantage de la machine, quelle qu'en soit la raison.
> Je me souviens m'être fait remarquer et souffler dans les
> bronches en bloquant totalement le Mini (je ne sais plus
> de quel fabriquant) de mon école d'ingénieur, qui a fini
> par planter et rebooter. Je faisais mumuse avec le C que
> je venais de découvrir, à grand coup de fork() dans tous
> les sens, sauf que personne (même pas moi) ne pouvait
> arrêter les process que j'avais lancés :-)
Ce n'est pas un plantage du noyau, c'est que le noyau n'a plus le
temps de traiter ce qu'on lui demande de traiter (et au passage,
c'est un problème de conception de ce noyau et de mauvaise gestion
des ressources).
Et ce genre de chose, tu peux le faire allègrement
sur certains Unix, Linux compris (en revanche, sur un NetBSD, tu risques
fort de te prendre un coup de pied aux fesses avec un message du type
'cannot fork'. Idem sous OpenBSD.). Ça ne plantera pas le noyau, ça
rendra la machine tellement lente qu'on la rebootera pour s'en
sortir.
On s'en fout, le résultat final est le même : la machine
doit être rebootée.
Quant à l'évolution des
fonctionnalités, elle ne justifie pas l'instabilité.
Ca explique, je n'ai pas dit que ça justifiait.
Mais il est
vrai que l'idéal du progrès a été remplacé par l'idéal de
l'innovation. Il ne s'agit pas que cela fonctionne mieux, mais que
cela soit nouveau, même si le fonctionnement est pire qu'avant.
Si ça apporte par ailleurs des fonctionnalités utiles, le bilan n'est pas forcément négatif, sachant que ce qui est temporairement dégradé peut être corrigé par la suite. Encore une fois tout dépend de l'usage.
Personnellement, je n'accepte pas un plantage d'une machine sur
autre chose qu'un problème matériel. Mais c'est mon côté dinosaure avec
des écailles.
Les dinosaures ont disparu faute d'avoir pu s'adapter : fait gaffe !
A part ça, je crois que ton killfile a encore planté : des
problèmes de stabilité ?
Le mardi 14 mai 2013 11:12:16 UTC+2, JKB a écrit :
>
> Je n'en sais rien pour VMS, mais tu peux faire planter
> à peu près n'importe unix avec des applications
> pathologiques en userland, si l'administrateur ne l'a
> l'a pas blindé de tous les côtés.
Non.
Si
Si une application userland plante le noyau (qui ne tourne pas
dans le même espace mémoire), c'est que ton noyau a un gros
problème.
C'est marrant comme tu changes les termes du problème
au cours de la discussion. Jusqu'à maintenant on parlait du
plantage de la machine, quelle qu'en soit la raison.
> Je me souviens m'être fait remarquer et souffler dans les
> bronches en bloquant totalement le Mini (je ne sais plus
> de quel fabriquant) de mon école d'ingénieur, qui a fini
> par planter et rebooter. Je faisais mumuse avec le C que
> je venais de découvrir, à grand coup de fork() dans tous
> les sens, sauf que personne (même pas moi) ne pouvait
> arrêter les process que j'avais lancés :-)
Ce n'est pas un plantage du noyau, c'est que le noyau n'a plus le
temps de traiter ce qu'on lui demande de traiter (et au passage,
c'est un problème de conception de ce noyau et de mauvaise gestion
des ressources).
Et ce genre de chose, tu peux le faire allègrement
sur certains Unix, Linux compris (en revanche, sur un NetBSD, tu risques
fort de te prendre un coup de pied aux fesses avec un message du type
'cannot fork'. Idem sous OpenBSD.). Ça ne plantera pas le noyau, ça
rendra la machine tellement lente qu'on la rebootera pour s'en
sortir.
On s'en fout, le résultat final est le même : la machine
doit être rebootée.
Quant à l'évolution des
fonctionnalités, elle ne justifie pas l'instabilité.
Ca explique, je n'ai pas dit que ça justifiait.Mais il est
vrai que l'idéal du progrès a été remplacé par l'idéal de
l'innovation. Il ne s'agit pas que cela fonctionne mieux, mais que
cela soit nouveau, même si le fonctionnement est pire qu'avant.
Si ça apporte par ailleurs des fonctionnalités utiles, le bilan n'est pas forcément négatif, sachant que ce qui est temporairement dégradé peut être corrigé par la suite. Encore une fois tout dépend de l'usage.
Personnellement, je n'accepte pas un plantage d'une machine sur
autre chose qu'un problème matériel. Mais c'est mon côté dinosaure avec
des écailles.
Les dinosaures ont disparu faute d'avoir pu s'adapter : fait gaffe !
A part ça, je crois que ton killfile a encore planté : des
problèmes de stabilité ?
>> > Je n'en sais rien pour VMS, mais tu peux faire planter
>> > à peu près n'importe unix avec des applications
>> > pathologiques en userland, si l'administrateur ne l'a
>> > l'a pas blindé de tous les côtés.
>>
>> Non.
> Si
Non. Un mauvais design du noyau n'est pas de la
responsabilité de l'administrateur.
> C'est marrant comme tu changes les termes du problème
> au cours de la discussion. Jusqu'à maintenant on parlait du
> plantage de la machine, quelle qu'en soit la raison.
Et je te répète que cela ne fait pas planter la machine. Ça la ren d
lente, inutilisable, et on la reboote pour retrouver ses petits
rapidement. Mais si l'administrateur a la patience d'attendre
d'avoir un shell actif avec un killall, ce qui peut prendre
plusieurs heures, je te l'accorde, il peut parfaitement tuer les
responsables.
>
> On s'en fout, le résultat final est le même : la machine
> doit être rebootée.
Non. On la reboote pour des raisons de simplicité. Le noyau n'est
_pas_ planté. J'ai un thésard qui m'a fait exactement ce que tu dis,
un fork() en boucle. Un serveur est monté à une charge de plus de
400. Comme il y avait des calculs en cours, on s'est démerdé pour ne
pas la rebooter. Avec de la patience, on y arrive parce qu'encore
une fois, le système est quasiment inutilisable mais pas planté !
> Si ça apporte par ailleurs des fonctionnalités utiles, le bilan
> n'est pas forcément négatif, sachant que ce qui est
> temporairement dégradé peut être corrigé par la suite. Encore
> une fois tout dépend de l'usage.
L'instabilité est une notion absolue.
> A part ça, je crois que ton killfile a encore planté : des
> problèmes de stabilité ?
La faute à un type qui change de pseudo régulièrement.
Et pour
répondre à la question suivante du même type, non, je ne filtre pa s
les adresse IP parce que pour un tas de contributeurs, ça ne sert à
rien.
>> > Je n'en sais rien pour VMS, mais tu peux faire planter
>> > à peu près n'importe unix avec des applications
>> > pathologiques en userland, si l'administrateur ne l'a
>> > l'a pas blindé de tous les côtés.
>>
>> Non.
> Si
Non. Un mauvais design du noyau n'est pas de la
responsabilité de l'administrateur.
> C'est marrant comme tu changes les termes du problème
> au cours de la discussion. Jusqu'à maintenant on parlait du
> plantage de la machine, quelle qu'en soit la raison.
Et je te répète que cela ne fait pas planter la machine. Ça la ren d
lente, inutilisable, et on la reboote pour retrouver ses petits
rapidement. Mais si l'administrateur a la patience d'attendre
d'avoir un shell actif avec un killall, ce qui peut prendre
plusieurs heures, je te l'accorde, il peut parfaitement tuer les
responsables.
>
> On s'en fout, le résultat final est le même : la machine
> doit être rebootée.
Non. On la reboote pour des raisons de simplicité. Le noyau n'est
_pas_ planté. J'ai un thésard qui m'a fait exactement ce que tu dis,
un fork() en boucle. Un serveur est monté à une charge de plus de
400. Comme il y avait des calculs en cours, on s'est démerdé pour ne
pas la rebooter. Avec de la patience, on y arrive parce qu'encore
une fois, le système est quasiment inutilisable mais pas planté !
> Si ça apporte par ailleurs des fonctionnalités utiles, le bilan
> n'est pas forcément négatif, sachant que ce qui est
> temporairement dégradé peut être corrigé par la suite. Encore
> une fois tout dépend de l'usage.
L'instabilité est une notion absolue.
> A part ça, je crois que ton killfile a encore planté : des
> problèmes de stabilité ?
La faute à un type qui change de pseudo régulièrement.
Et pour
répondre à la question suivante du même type, non, je ne filtre pa s
les adresse IP parce que pour un tas de contributeurs, ça ne sert à
rien.
>> > Je n'en sais rien pour VMS, mais tu peux faire planter
>> > à peu près n'importe unix avec des applications
>> > pathologiques en userland, si l'administrateur ne l'a
>> > l'a pas blindé de tous les côtés.
>>
>> Non.
> Si
Non. Un mauvais design du noyau n'est pas de la
responsabilité de l'administrateur.
> C'est marrant comme tu changes les termes du problème
> au cours de la discussion. Jusqu'à maintenant on parlait du
> plantage de la machine, quelle qu'en soit la raison.
Et je te répète que cela ne fait pas planter la machine. Ça la ren d
lente, inutilisable, et on la reboote pour retrouver ses petits
rapidement. Mais si l'administrateur a la patience d'attendre
d'avoir un shell actif avec un killall, ce qui peut prendre
plusieurs heures, je te l'accorde, il peut parfaitement tuer les
responsables.
>
> On s'en fout, le résultat final est le même : la machine
> doit être rebootée.
Non. On la reboote pour des raisons de simplicité. Le noyau n'est
_pas_ planté. J'ai un thésard qui m'a fait exactement ce que tu dis,
un fork() en boucle. Un serveur est monté à une charge de plus de
400. Comme il y avait des calculs en cours, on s'est démerdé pour ne
pas la rebooter. Avec de la patience, on y arrive parce qu'encore
une fois, le système est quasiment inutilisable mais pas planté !
> Si ça apporte par ailleurs des fonctionnalités utiles, le bilan
> n'est pas forcément négatif, sachant que ce qui est
> temporairement dégradé peut être corrigé par la suite. Encore
> une fois tout dépend de l'usage.
L'instabilité est une notion absolue.
> A part ça, je crois que ton killfile a encore planté : des
> problèmes de stabilité ?
La faute à un type qui change de pseudo régulièrement.
Et pour
répondre à la question suivante du même type, non, je ne filtre pa s
les adresse IP parce que pour un tas de contributeurs, ça ne sert à
rien.
Le mardi 14 mai 2013 11:56:10 UTC+2, JKB a écrit :
>> > Je n'en sais rien pour VMS, mais tu peux faire planter
>> > à peu près n'importe unix avec des applications
>> > pathologiques en userland, si l'administrateur ne l'a
>> > l'a pas blindé de tous les côtés.
>>
>> Non.
> Si
Non. Un mauvais design du noyau n'est pas de la
responsabilité de l'administrateur.
L'administrateur peut poser des limites genre nombre maximum
de process pour un utilisateur, etc.
> C'est marrant comme tu changes les termes du problème
> au cours de la discussion. Jusqu'à maintenant on parlait du
> plantage de la machine, quelle qu'en soit la raison.
Et je te répète que cela ne fait pas planter la machine. Ça la rend
lente, inutilisable, et on la reboote pour retrouver ses petits
rapidement. Mais si l'administrateur a la patience d'attendre
d'avoir un shell actif avec un killall, ce qui peut prendre
plusieurs heures, je te l'accorde, il peut parfaitement tuer les
responsables.
>
> On s'en fout, le résultat final est le même : la machine
> doit être rebootée.
Non. On la reboote pour des raisons de simplicité. Le noyau n'est
_pas_ planté. J'ai un thésard qui m'a fait exactement ce que tu dis,
un fork() en boucle. Un serveur est monté à une charge de plus de
400. Comme il y avait des calculs en cours, on s'est démerdé pour ne
pas la rebooter. Avec de la patience, on y arrive parce qu'encore
une fois, le système est quasiment inutilisable mais pas planté !
Si tu y vas par là, les plantages sous Windows ne sont pas tous des
kernel panic non plus, et quelqu'un de motivé et qui connait l'OS doit
pouvoir débloquer la machine sans la rebooter là aussi. Sauf qu'en général
on perd moins de temps à rebooter.
> Si ça apporte par ailleurs des fonctionnalités utiles, le bilan
> n'est pas forcément négatif, sachant que ce qui est
> temporairement dégradé peut être corrigé par la suite. Encore
> une fois tout dépend de l'usage.
L'instabilité est une notion absolue.
OK OK, j'ai bien compris que pour poster sur usenet tu avais besoin
d'une machine avec un uptime de 11 ans. Je respecte.
> A part ça, je crois que ton killfile a encore planté : des
> problèmes de stabilité ?
La faute à un type qui change de pseudo régulièrement.
Foutaises. Je n'ai que 2 façons de poster sur usenet : sur mon ordi
principal avec TB, ou bien par Google Groups. Sur le premier je n'ai
pas changé de pseudo depuis 3 ans (et même avant il y avait toujours
"pehache" dedans). Sur le second il est vrai que GG
en fait un peu à sa tête pour l'affichage du pseudo, mais ça ne change
pas tous les 4 matins non plus.
Et pour
répondre à la question suivante du même type, non, je ne filtre pas
les adresse IP parce que pour un tas de contributeurs, ça ne sert à
rien.
Tu n'as pas encore compris qu'il fallait filtrer sur l'adresse email ?
Je te l'ai déjà dit pourtant ! J'utilise la même adresse email depuis
6 ans pour poster.
Ou alors la fonctionnalité de filtrage sur l'email n'est pas
encore arrivée sur la version parfaitement stable de slrn
qui tu utilises et qui date de 11 ans :-) ?
Le mardi 14 mai 2013 11:56:10 UTC+2, JKB a écrit :
>> > Je n'en sais rien pour VMS, mais tu peux faire planter
>> > à peu près n'importe unix avec des applications
>> > pathologiques en userland, si l'administrateur ne l'a
>> > l'a pas blindé de tous les côtés.
>>
>> Non.
> Si
Non. Un mauvais design du noyau n'est pas de la
responsabilité de l'administrateur.
L'administrateur peut poser des limites genre nombre maximum
de process pour un utilisateur, etc.
> C'est marrant comme tu changes les termes du problème
> au cours de la discussion. Jusqu'à maintenant on parlait du
> plantage de la machine, quelle qu'en soit la raison.
Et je te répète que cela ne fait pas planter la machine. Ça la rend
lente, inutilisable, et on la reboote pour retrouver ses petits
rapidement. Mais si l'administrateur a la patience d'attendre
d'avoir un shell actif avec un killall, ce qui peut prendre
plusieurs heures, je te l'accorde, il peut parfaitement tuer les
responsables.
>
> On s'en fout, le résultat final est le même : la machine
> doit être rebootée.
Non. On la reboote pour des raisons de simplicité. Le noyau n'est
_pas_ planté. J'ai un thésard qui m'a fait exactement ce que tu dis,
un fork() en boucle. Un serveur est monté à une charge de plus de
400. Comme il y avait des calculs en cours, on s'est démerdé pour ne
pas la rebooter. Avec de la patience, on y arrive parce qu'encore
une fois, le système est quasiment inutilisable mais pas planté !
Si tu y vas par là, les plantages sous Windows ne sont pas tous des
kernel panic non plus, et quelqu'un de motivé et qui connait l'OS doit
pouvoir débloquer la machine sans la rebooter là aussi. Sauf qu'en général
on perd moins de temps à rebooter.
> Si ça apporte par ailleurs des fonctionnalités utiles, le bilan
> n'est pas forcément négatif, sachant que ce qui est
> temporairement dégradé peut être corrigé par la suite. Encore
> une fois tout dépend de l'usage.
L'instabilité est une notion absolue.
OK OK, j'ai bien compris que pour poster sur usenet tu avais besoin
d'une machine avec un uptime de 11 ans. Je respecte.
> A part ça, je crois que ton killfile a encore planté : des
> problèmes de stabilité ?
La faute à un type qui change de pseudo régulièrement.
Foutaises. Je n'ai que 2 façons de poster sur usenet : sur mon ordi
principal avec TB, ou bien par Google Groups. Sur le premier je n'ai
pas changé de pseudo depuis 3 ans (et même avant il y avait toujours
"pehache" dedans). Sur le second il est vrai que GG
en fait un peu à sa tête pour l'affichage du pseudo, mais ça ne change
pas tous les 4 matins non plus.
Et pour
répondre à la question suivante du même type, non, je ne filtre pas
les adresse IP parce que pour un tas de contributeurs, ça ne sert à
rien.
Tu n'as pas encore compris qu'il fallait filtrer sur l'adresse email ?
Je te l'ai déjà dit pourtant ! J'utilise la même adresse email depuis
6 ans pour poster.
Ou alors la fonctionnalité de filtrage sur l'email n'est pas
encore arrivée sur la version parfaitement stable de slrn
qui tu utilises et qui date de 11 ans :-) ?
Le mardi 14 mai 2013 11:56:10 UTC+2, JKB a écrit :
>> > Je n'en sais rien pour VMS, mais tu peux faire planter
>> > à peu près n'importe unix avec des applications
>> > pathologiques en userland, si l'administrateur ne l'a
>> > l'a pas blindé de tous les côtés.
>>
>> Non.
> Si
Non. Un mauvais design du noyau n'est pas de la
responsabilité de l'administrateur.
L'administrateur peut poser des limites genre nombre maximum
de process pour un utilisateur, etc.
> C'est marrant comme tu changes les termes du problème
> au cours de la discussion. Jusqu'à maintenant on parlait du
> plantage de la machine, quelle qu'en soit la raison.
Et je te répète que cela ne fait pas planter la machine. Ça la rend
lente, inutilisable, et on la reboote pour retrouver ses petits
rapidement. Mais si l'administrateur a la patience d'attendre
d'avoir un shell actif avec un killall, ce qui peut prendre
plusieurs heures, je te l'accorde, il peut parfaitement tuer les
responsables.
>
> On s'en fout, le résultat final est le même : la machine
> doit être rebootée.
Non. On la reboote pour des raisons de simplicité. Le noyau n'est
_pas_ planté. J'ai un thésard qui m'a fait exactement ce que tu dis,
un fork() en boucle. Un serveur est monté à une charge de plus de
400. Comme il y avait des calculs en cours, on s'est démerdé pour ne
pas la rebooter. Avec de la patience, on y arrive parce qu'encore
une fois, le système est quasiment inutilisable mais pas planté !
Si tu y vas par là, les plantages sous Windows ne sont pas tous des
kernel panic non plus, et quelqu'un de motivé et qui connait l'OS doit
pouvoir débloquer la machine sans la rebooter là aussi. Sauf qu'en général
on perd moins de temps à rebooter.
> Si ça apporte par ailleurs des fonctionnalités utiles, le bilan
> n'est pas forcément négatif, sachant que ce qui est
> temporairement dégradé peut être corrigé par la suite. Encore
> une fois tout dépend de l'usage.
L'instabilité est une notion absolue.
OK OK, j'ai bien compris que pour poster sur usenet tu avais besoin
d'une machine avec un uptime de 11 ans. Je respecte.
> A part ça, je crois que ton killfile a encore planté : des
> problèmes de stabilité ?
La faute à un type qui change de pseudo régulièrement.
Foutaises. Je n'ai que 2 façons de poster sur usenet : sur mon ordi
principal avec TB, ou bien par Google Groups. Sur le premier je n'ai
pas changé de pseudo depuis 3 ans (et même avant il y avait toujours
"pehache" dedans). Sur le second il est vrai que GG
en fait un peu à sa tête pour l'affichage du pseudo, mais ça ne change
pas tous les 4 matins non plus.
Et pour
répondre à la question suivante du même type, non, je ne filtre pas
les adresse IP parce que pour un tas de contributeurs, ça ne sert à
rien.
Tu n'as pas encore compris qu'il fallait filtrer sur l'adresse email ?
Je te l'ai déjà dit pourtant ! J'utilise la même adresse email depuis
6 ans pour poster.
Ou alors la fonctionnalité de filtrage sur l'email n'est pas
encore arrivée sur la version parfaitement stable de slrn
qui tu utilises et qui date de 11 ans :-) ?
> Si tu y vas par là, les plantages sous Windows ne sont pas tous des
> kernel panic non plus, et quelqu'un de motivé et qui connait l'OS doi t
> pouvoir débloquer la machine sans la rebooter là aussi. Sauf qu'en général
> on perd moins de temps à rebooter.
Sauf que je vois beaucoup plus d'écrans bleus (même s ous W7) que je
n'ai jamais vu de panics ou de oops sous tous les unixo ïdes qui me
sont passé entre les mains. Un panic (ou un écran ble u), c'est un
aterrussage forcé du noyau qui demande un redémarrage . C'est
totalement différent d'une bombe fork.
> OK OK, j'ai bien compris que pour poster sur usenet tu avais besoin
> d'une machine avec un uptime de 11 ans. Je respecte.
Lamentable. Et je ne vois pas le rapport. Et si une machi ne a une
probabilité de disponibilité de 99,995 % (utilisé p our les faisceaux
hertziens), elle va être indisponible quelques secondes par an. Qui
me dit qu'elle ne va pas planter en plein milieu de l'é criture de
cette réponse ?
Une machine est stable ou ne l'est pas. Si elle ne
l'est pas, je ne lui fait absolument pas confiance.
> Foutaises. Je n'ai que 2 façons de poster sur usenet : sur mon ordi
> principal avec TB, ou bien par Google Groups. Sur le premier je n'ai
> pas changé de pseudo depuis 3 ans (et même avant il y avait toujour s
> "pehache" dedans). Sur le second il est vrai que GG
> en fait un peu à sa tête pour l'affichage du pseudo, mais ça ne c hange
> pas tous les 4 matins non plus.
Sauf que tu n'es pas seul et que j'ai d'autres choses à faire que de
mettre en place des systèmes de filtres différents pa r importun. La
majorité est filtré sur les pseudos et ça fonctionn e.
C'est à toi
d'avoir la politesse de garder toujours le même. Dans l e cas
contraire, ne viens pas te plaindre que je réponds à tes arguties.
> Tu n'as pas encore compris qu'il fallait filtrer sur l'adresse email ?
> Je te l'ai déjà dit pourtant ! J'utilise la même adresse email de puis
> 6 ans pour poster.
Non, j'ai plusieurs lignes correspondant à tes adresses mail
prétendument uniques.
> Ou alors la fonctionnalité de filtrage sur l'email n'est pas
> encore arrivée sur la version parfaitement stable de slrn
> qui tu utilises et qui date de 11 ans :-) ?
Un smiley ne rend pas ton propos plus intelligent.
> Si tu y vas par là, les plantages sous Windows ne sont pas tous des
> kernel panic non plus, et quelqu'un de motivé et qui connait l'OS doi t
> pouvoir débloquer la machine sans la rebooter là aussi. Sauf qu'en général
> on perd moins de temps à rebooter.
Sauf que je vois beaucoup plus d'écrans bleus (même s ous W7) que je
n'ai jamais vu de panics ou de oops sous tous les unixo ïdes qui me
sont passé entre les mains. Un panic (ou un écran ble u), c'est un
aterrussage forcé du noyau qui demande un redémarrage . C'est
totalement différent d'une bombe fork.
> OK OK, j'ai bien compris que pour poster sur usenet tu avais besoin
> d'une machine avec un uptime de 11 ans. Je respecte.
Lamentable. Et je ne vois pas le rapport. Et si une machi ne a une
probabilité de disponibilité de 99,995 % (utilisé p our les faisceaux
hertziens), elle va être indisponible quelques secondes par an. Qui
me dit qu'elle ne va pas planter en plein milieu de l'é criture de
cette réponse ?
Une machine est stable ou ne l'est pas. Si elle ne
l'est pas, je ne lui fait absolument pas confiance.
> Foutaises. Je n'ai que 2 façons de poster sur usenet : sur mon ordi
> principal avec TB, ou bien par Google Groups. Sur le premier je n'ai
> pas changé de pseudo depuis 3 ans (et même avant il y avait toujour s
> "pehache" dedans). Sur le second il est vrai que GG
> en fait un peu à sa tête pour l'affichage du pseudo, mais ça ne c hange
> pas tous les 4 matins non plus.
Sauf que tu n'es pas seul et que j'ai d'autres choses à faire que de
mettre en place des systèmes de filtres différents pa r importun. La
majorité est filtré sur les pseudos et ça fonctionn e.
C'est à toi
d'avoir la politesse de garder toujours le même. Dans l e cas
contraire, ne viens pas te plaindre que je réponds à tes arguties.
> Tu n'as pas encore compris qu'il fallait filtrer sur l'adresse email ?
> Je te l'ai déjà dit pourtant ! J'utilise la même adresse email de puis
> 6 ans pour poster.
Non, j'ai plusieurs lignes correspondant à tes adresses mail
prétendument uniques.
> Ou alors la fonctionnalité de filtrage sur l'email n'est pas
> encore arrivée sur la version parfaitement stable de slrn
> qui tu utilises et qui date de 11 ans :-) ?
Un smiley ne rend pas ton propos plus intelligent.
> Si tu y vas par là, les plantages sous Windows ne sont pas tous des
> kernel panic non plus, et quelqu'un de motivé et qui connait l'OS doi t
> pouvoir débloquer la machine sans la rebooter là aussi. Sauf qu'en général
> on perd moins de temps à rebooter.
Sauf que je vois beaucoup plus d'écrans bleus (même s ous W7) que je
n'ai jamais vu de panics ou de oops sous tous les unixo ïdes qui me
sont passé entre les mains. Un panic (ou un écran ble u), c'est un
aterrussage forcé du noyau qui demande un redémarrage . C'est
totalement différent d'une bombe fork.
> OK OK, j'ai bien compris que pour poster sur usenet tu avais besoin
> d'une machine avec un uptime de 11 ans. Je respecte.
Lamentable. Et je ne vois pas le rapport. Et si une machi ne a une
probabilité de disponibilité de 99,995 % (utilisé p our les faisceaux
hertziens), elle va être indisponible quelques secondes par an. Qui
me dit qu'elle ne va pas planter en plein milieu de l'é criture de
cette réponse ?
Une machine est stable ou ne l'est pas. Si elle ne
l'est pas, je ne lui fait absolument pas confiance.
> Foutaises. Je n'ai que 2 façons de poster sur usenet : sur mon ordi
> principal avec TB, ou bien par Google Groups. Sur le premier je n'ai
> pas changé de pseudo depuis 3 ans (et même avant il y avait toujour s
> "pehache" dedans). Sur le second il est vrai que GG
> en fait un peu à sa tête pour l'affichage du pseudo, mais ça ne c hange
> pas tous les 4 matins non plus.
Sauf que tu n'es pas seul et que j'ai d'autres choses à faire que de
mettre en place des systèmes de filtres différents pa r importun. La
majorité est filtré sur les pseudos et ça fonctionn e.
C'est à toi
d'avoir la politesse de garder toujours le même. Dans l e cas
contraire, ne viens pas te plaindre que je réponds à tes arguties.
> Tu n'as pas encore compris qu'il fallait filtrer sur l'adresse email ?
> Je te l'ai déjà dit pourtant ! J'utilise la même adresse email de puis
> 6 ans pour poster.
Non, j'ai plusieurs lignes correspondant à tes adresses mail
prétendument uniques.
> Ou alors la fonctionnalité de filtrage sur l'email n'est pas
> encore arrivée sur la version parfaitement stable de slrn
> qui tu utilises et qui date de 11 ans :-) ?
Un smiley ne rend pas ton propos plus intelligent.
sont passé entre les mains. Un panic (ou un écran bleu), c'est un
aterrussage forcé du noyau qui demande un redémarrage. C'est
totalement différent d'une bombe fork.
Des kernel panic sur des unixeries j'en ai déjà vu et je ne suis pas
le seul. Tu ne vas tout de même pas prétendre que ça n'existe pas ??
sont passé entre les mains. Un panic (ou un écran bleu), c'est un
aterrussage forcé du noyau qui demande un redémarrage. C'est
totalement différent d'une bombe fork.
Des kernel panic sur des unixeries j'en ai déjà vu et je ne suis pas
le seul. Tu ne vas tout de même pas prétendre que ça n'existe pas ??
sont passé entre les mains. Un panic (ou un écran bleu), c'est un
aterrussage forcé du noyau qui demande un redémarrage. C'est
totalement différent d'une bombe fork.
Des kernel panic sur des unixeries j'en ai déjà vu et je ne suis pas
le seul. Tu ne vas tout de même pas prétendre que ça n'existe pas ??
