Non. En SCSI (ou assimilé : SAS, FCAL...), le contrôleur est sur le disque. En IDE ou SATA, le contrôleur est sur la carte-mère.
Tu parles de quel contrôleur ? Le contrôleur disque est toujours intégré au disque aussi bien en IDE/PATA et aujourd'hui en SATA qu'en SCSI. C'était même une caractéristique distinctive de l'IDE qui signifie "Intelligent Drive Electronics" par rapport à son prédécesseur ST506 dont il a repris la compatibilité logicielle. Le contrôleur hôte IDE sur la carte mère n'est qu'une interface de bus, comme en SCSI. Qu'un contrôleur disque IDE/ATA n'ait pas autant de fonctionnalités qu'en SCSI, je veux bien l'admettre. Mais comme il est le seul à connaître la géométrie réelle des plateaux, il doit bien être intégré au disque.
JKB a écrit :
Non. En SCSI (ou assimilé : SAS, FCAL...), le contrôleur est sur le
disque. En IDE ou SATA, le contrôleur est sur la carte-mère.
Tu parles de quel contrôleur ?
Le contrôleur disque est toujours intégré au disque aussi bien en
IDE/PATA et aujourd'hui en SATA qu'en SCSI. C'était même une
caractéristique distinctive de l'IDE qui signifie "Intelligent Drive
Electronics" par rapport à son prédécesseur ST506 dont il a repris la
compatibilité logicielle. Le contrôleur hôte IDE sur la carte mère n'est
qu'une interface de bus, comme en SCSI. Qu'un contrôleur disque IDE/ATA
n'ait pas autant de fonctionnalités qu'en SCSI, je veux bien l'admettre.
Mais comme il est le seul à connaître la géométrie réelle des plateaux,
il doit bien être intégré au disque.
Non. En SCSI (ou assimilé : SAS, FCAL...), le contrôleur est sur le disque. En IDE ou SATA, le contrôleur est sur la carte-mère.
Tu parles de quel contrôleur ? Le contrôleur disque est toujours intégré au disque aussi bien en IDE/PATA et aujourd'hui en SATA qu'en SCSI. C'était même une caractéristique distinctive de l'IDE qui signifie "Intelligent Drive Electronics" par rapport à son prédécesseur ST506 dont il a repris la compatibilité logicielle. Le contrôleur hôte IDE sur la carte mère n'est qu'une interface de bus, comme en SCSI. Qu'un contrôleur disque IDE/ATA n'ait pas autant de fonctionnalités qu'en SCSI, je veux bien l'admettre. Mais comme il est le seul à connaître la géométrie réelle des plateaux, il doit bien être intégré au disque.
JKB
Le 16-01-2010, ? propos de Re: problème raid, Nicolas George ?crivait dans fr.comp.os.linux.configuration :
JKB wrote in message :
J'ai eu le coup avec une stable lors d'une mise à jour de _sécurité_ qui m'a changé le noyau moisi 2.6.25 contre un plus récent.
Ça, je n'y crois pas une seule seconde, c'est complètement contraire à la politique de Debian. Il est plus probable que tu aies fait une erreur de manipulation.
Tout le monde peut faire des boulettes, les devs de debian comme les autres (toi compris). Le problème a même été remonté sur les listes des devs debian qui s'en sont pris plein sur les doigts. Après, que tu ne me crois pas, ce n'est pas mon problème.
D'ailleurs ça peut se vérifier maintenant : le noyau de Lenny est un 2.6.26, le noyau d'Etch'n'half est un 2.6.24, le noyau d'Etch est un 2.6.18. Il n'y a pas de noyau 2.6.25 dans une Debian stable.
Je dois avoir des visions :
:~$ uname -a Linux cervantes 2.6.25-2-amd64 #1 SMP Fri Jun 27 00:16:12 UTC 2008 x86_64 GNU/Linux :~$ cat /etc/issue Debian GNU/Linux 5.0 n l
:~$ dpkg-query -l | grep image-2.6.25-2-amd64 ii linux-image-2.6.25-2-amd64 2.6.25-6 Linux 2.6.25 image on AMD64 :/boot$
J'ai comme l'impression que lenny est une debian stable, vu que squeeze est la testing et que sid reste l'instable à vie. Et que tu le veuilles ou non, il y a eu à un moment, un noyau 2.6.25-2 dans lenny. Après, que le noyau ne soit pas à jour, ça s'explique par un certain nombre de dysfonctionnements de samba qui refuse sur ledit réseau de fonctionner correctement avec un noyau plus récent sauf à passer à une version de samba plus récente qui merdoie allègrement (pour cause de verrous sur les fichiers posés par cette saleté de Pervasive, de Visiodent et de profils itinérants, mais c'est un autre débat !).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 16-01-2010, ? propos de
Re: problème raid,
Nicolas George ?crivait dans fr.comp.os.linux.configuration :
JKB wrote in message <slrnhl2u8p.vk0.knatschke@rayleigh.systella.fr>:
J'ai eu le coup avec une stable
lors d'une mise à jour de _sécurité_ qui m'a changé le noyau moisi
2.6.25 contre un plus récent.
Ça, je n'y crois pas une seule seconde, c'est complètement contraire à la
politique de Debian. Il est plus probable que tu aies fait une erreur de
manipulation.
Tout le monde peut faire des boulettes, les devs de debian comme les
autres (toi compris). Le problème a même été remonté sur les listes
des devs debian qui s'en sont pris plein sur les doigts. Après, que
tu ne me crois pas, ce n'est pas mon problème.
D'ailleurs ça peut se vérifier maintenant : le noyau de Lenny est un 2.6.26,
le noyau d'Etch'n'half est un 2.6.24, le noyau d'Etch est un 2.6.18. Il n'y
a pas de noyau 2.6.25 dans une Debian stable.
Je dois avoir des visions :
local@cervantes:~$ uname -a
Linux cervantes 2.6.25-2-amd64 #1 SMP Fri Jun 27 00:16:12 UTC 2008
x86_64 GNU/Linux
local@cervantes:~$ cat /etc/issue
Debian GNU/Linux 5.0 n l
local@cervantes:~$ dpkg-query -l | grep image-2.6.25-2-amd64
ii linux-image-2.6.25-2-amd64 2.6.25-6
Linux 2.6.25 image on AMD64
local@cervantes:/boot$
J'ai comme l'impression que lenny est une debian stable, vu que
squeeze est la testing et que sid reste l'instable à vie. Et que tu
le veuilles ou non, il y a eu à un moment, un noyau 2.6.25-2 dans
lenny. Après, que le noyau ne soit pas à jour, ça s'explique par un
certain nombre de dysfonctionnements de samba qui refuse sur ledit
réseau de fonctionner correctement avec un noyau plus récent sauf à
passer à une version de samba plus récente qui merdoie allègrement
(pour cause de verrous sur les fichiers posés par cette saleté de
Pervasive, de Visiodent et de profils itinérants, mais c'est un
autre débat !).
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 16-01-2010, ? propos de Re: problème raid, Nicolas George ?crivait dans fr.comp.os.linux.configuration :
JKB wrote in message :
J'ai eu le coup avec une stable lors d'une mise à jour de _sécurité_ qui m'a changé le noyau moisi 2.6.25 contre un plus récent.
Ça, je n'y crois pas une seule seconde, c'est complètement contraire à la politique de Debian. Il est plus probable que tu aies fait une erreur de manipulation.
Tout le monde peut faire des boulettes, les devs de debian comme les autres (toi compris). Le problème a même été remonté sur les listes des devs debian qui s'en sont pris plein sur les doigts. Après, que tu ne me crois pas, ce n'est pas mon problème.
D'ailleurs ça peut se vérifier maintenant : le noyau de Lenny est un 2.6.26, le noyau d'Etch'n'half est un 2.6.24, le noyau d'Etch est un 2.6.18. Il n'y a pas de noyau 2.6.25 dans une Debian stable.
Je dois avoir des visions :
:~$ uname -a Linux cervantes 2.6.25-2-amd64 #1 SMP Fri Jun 27 00:16:12 UTC 2008 x86_64 GNU/Linux :~$ cat /etc/issue Debian GNU/Linux 5.0 n l
:~$ dpkg-query -l | grep image-2.6.25-2-amd64 ii linux-image-2.6.25-2-amd64 2.6.25-6 Linux 2.6.25 image on AMD64 :/boot$
J'ai comme l'impression que lenny est une debian stable, vu que squeeze est la testing et que sid reste l'instable à vie. Et que tu le veuilles ou non, il y a eu à un moment, un noyau 2.6.25-2 dans lenny. Après, que le noyau ne soit pas à jour, ça s'explique par un certain nombre de dysfonctionnements de samba qui refuse sur ledit réseau de fonctionner correctement avec un noyau plus récent sauf à passer à une version de samba plus récente qui merdoie allègrement (pour cause de verrous sur les fichiers posés par cette saleté de Pervasive, de Visiodent et de profils itinérants, mais c'est un autre débat !).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 16-01-2010, ? propos de Re: problème raid, Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
Salut,
JKB a écrit :
Fabien LE LEZ ?crivait dans fr.comp.os.linux.configuration :
Je parle de stable et de testing. J'ai eu le coup avec une stable lors d'une mise à jour de _sécurité_ qui m'a changé le noyau moisi 2.6.25 contre un plus récent.
Ton témoignage me laisses perplexe. D'une part, à ma connaissance il n'y a jamais eu de noyau 2.6.25 dans Debian stable, et d'autre part la version du noyau stable ne change pas. Quand bien même elle changerait, le remplacement ne pourrait pas se faire avec un simple upgrade qui ne peut pas installer de nouveaux paquets, il faudrait un dist-upgrade.
Dans ce cas, explique-moi comment je me suis retrouvé avec un 2.6.25-2 (machine installée en etch et passée en lenny puis plus rien).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 16-01-2010, ? propos de
Re: problème raid,
Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
Salut,
JKB a écrit :
Fabien LE LEZ ?crivait dans fr.comp.os.linux.configuration :
Je parle de stable et de testing. J'ai eu le coup avec une stable
lors d'une mise à jour de _sécurité_ qui m'a changé le noyau moisi
2.6.25 contre un plus récent.
Ton témoignage me laisses perplexe.
D'une part, à ma connaissance il n'y a jamais eu de noyau 2.6.25 dans
Debian stable, et d'autre part la version du noyau stable ne change pas.
Quand bien même elle changerait, le remplacement ne pourrait pas se
faire avec un simple upgrade qui ne peut pas installer de nouveaux
paquets, il faudrait un dist-upgrade.
Dans ce cas, explique-moi comment je me suis retrouvé avec un
2.6.25-2 (machine installée en etch et passée en lenny puis plus
rien).
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 16-01-2010, ? propos de Re: problème raid, Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
Salut,
JKB a écrit :
Fabien LE LEZ ?crivait dans fr.comp.os.linux.configuration :
Je parle de stable et de testing. J'ai eu le coup avec une stable lors d'une mise à jour de _sécurité_ qui m'a changé le noyau moisi 2.6.25 contre un plus récent.
Ton témoignage me laisses perplexe. D'une part, à ma connaissance il n'y a jamais eu de noyau 2.6.25 dans Debian stable, et d'autre part la version du noyau stable ne change pas. Quand bien même elle changerait, le remplacement ne pourrait pas se faire avec un simple upgrade qui ne peut pas installer de nouveaux paquets, il faudrait un dist-upgrade.
Dans ce cas, explique-moi comment je me suis retrouvé avec un 2.6.25-2 (machine installée en etch et passée en lenny puis plus rien).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 16-01-2010, ? propos de Re: problème raid, Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
JKB a écrit :
Non. En SCSI (ou assimilé : SAS, FCAL...), le contrôleur est sur le disque. En IDE ou SATA, le contrôleur est sur la carte-mère.
Tu parles de quel contrôleur ? Le contrôleur disque est toujours intégré au disque aussi bien en IDE/PATA et aujourd'hui en SATA qu'en SCSI. C'était même une caractéristique distinctive de l'IDE qui signifie "Intelligent Drive Electronics" par rapport à son prédécesseur ST506 dont il a repris la compatibilité logicielle. Le contrôleur hôte IDE sur la carte mère n'est qu'une interface de bus, comme en SCSI. Qu'un contrôleur disque IDE/ATA n'ait pas autant de fonctionnalités qu'en SCSI, je veux bien l'admettre. Mais comme il est le seul à connaître la géométrie réelle des plateaux, il doit bien être intégré au disque.
Je suis de la vieille école (qui plus est électronique) dans laquelle on parlait d'interface et de contrôleur en faisant la différence entre les deux. Dans cette école là, celle des années 80, on parlait en IDE ou ST506 de contrôleur sur la carte-mère et d'interface sur le disque, alors que pour le SCSI, on parlait d'interface sur la carte-mère et de contrôleur sur le disque. Maintenant, je ne vais pas me battre sur des termes d'autant plus qu'on s'est mis à mélanger allègrement les deux. L'IDE a été conçu à l'époque pour minimiser la complexité de l'électronique embarquée sur le disque et ainsi les coûts.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 16-01-2010, ? propos de
Re: problème raid,
Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
JKB a écrit :
Non. En SCSI (ou assimilé : SAS, FCAL...), le contrôleur est sur le
disque. En IDE ou SATA, le contrôleur est sur la carte-mère.
Tu parles de quel contrôleur ?
Le contrôleur disque est toujours intégré au disque aussi bien en
IDE/PATA et aujourd'hui en SATA qu'en SCSI. C'était même une
caractéristique distinctive de l'IDE qui signifie "Intelligent Drive
Electronics" par rapport à son prédécesseur ST506 dont il a repris la
compatibilité logicielle. Le contrôleur hôte IDE sur la carte mère n'est
qu'une interface de bus, comme en SCSI. Qu'un contrôleur disque IDE/ATA
n'ait pas autant de fonctionnalités qu'en SCSI, je veux bien l'admettre.
Mais comme il est le seul à connaître la géométrie réelle des plateaux,
il doit bien être intégré au disque.
Je suis de la vieille école (qui plus est électronique) dans laquelle
on parlait d'interface et de contrôleur en faisant la différence entre
les deux. Dans cette école là, celle des années 80, on parlait en IDE
ou ST506 de contrôleur sur la carte-mère et d'interface sur le disque,
alors que pour le SCSI, on parlait d'interface sur la carte-mère et de
contrôleur sur le disque. Maintenant, je ne vais pas me battre sur
des termes d'autant plus qu'on s'est mis à mélanger allègrement les
deux. L'IDE a été conçu à l'époque pour minimiser la complexité de
l'électronique embarquée sur le disque et ainsi les coûts.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 16-01-2010, ? propos de Re: problème raid, Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
JKB a écrit :
Non. En SCSI (ou assimilé : SAS, FCAL...), le contrôleur est sur le disque. En IDE ou SATA, le contrôleur est sur la carte-mère.
Tu parles de quel contrôleur ? Le contrôleur disque est toujours intégré au disque aussi bien en IDE/PATA et aujourd'hui en SATA qu'en SCSI. C'était même une caractéristique distinctive de l'IDE qui signifie "Intelligent Drive Electronics" par rapport à son prédécesseur ST506 dont il a repris la compatibilité logicielle. Le contrôleur hôte IDE sur la carte mère n'est qu'une interface de bus, comme en SCSI. Qu'un contrôleur disque IDE/ATA n'ait pas autant de fonctionnalités qu'en SCSI, je veux bien l'admettre. Mais comme il est le seul à connaître la géométrie réelle des plateaux, il doit bien être intégré au disque.
Je suis de la vieille école (qui plus est électronique) dans laquelle on parlait d'interface et de contrôleur en faisant la différence entre les deux. Dans cette école là, celle des années 80, on parlait en IDE ou ST506 de contrôleur sur la carte-mère et d'interface sur le disque, alors que pour le SCSI, on parlait d'interface sur la carte-mère et de contrôleur sur le disque. Maintenant, je ne vais pas me battre sur des termes d'autant plus qu'on s'est mis à mélanger allègrement les deux. L'IDE a été conçu à l'époque pour minimiser la complexité de l'électronique embarquée sur le disque et ainsi les coûts.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Nicolas George
JKB wrote in message :
Tout le monde peut faire des boulettes, les devs de debian comme les autres (toi compris). Le problème a même été remonté sur les listes des devs debian qui s'en sont pris plein sur les doigts. Après, que tu ne me crois pas, ce n'est pas mon problème.
Si c'est sur les listes de développement de Debian, tu dois avoir facilement des pointeurs vers les archives.
Et même si c'est vrai, une boulette de développeurs Debian, ce n'est pas la même chose qu'une politique mauvaise des développeurs du noyau.
J'ai comme l'impression que lenny est une debian stable
Et avant d'être une stable, c'était une testing. À ce moment-là, elle a très bien pu avoir un noyau 2.6.25.
JKB wrote in message <slrnhl346c.vk0.knatschke@rayleigh.systella.fr>:
Tout le monde peut faire des boulettes, les devs de debian comme les
autres (toi compris). Le problème a même été remonté sur les listes
des devs debian qui s'en sont pris plein sur les doigts. Après, que
tu ne me crois pas, ce n'est pas mon problème.
Si c'est sur les listes de développement de Debian, tu dois avoir facilement
des pointeurs vers les archives.
Et même si c'est vrai, une boulette de développeurs Debian, ce n'est pas la
même chose qu'une politique mauvaise des développeurs du noyau.
J'ai comme l'impression que lenny est une debian stable
Et avant d'être une stable, c'était une testing. À ce moment-là, elle a très
bien pu avoir un noyau 2.6.25.
Tout le monde peut faire des boulettes, les devs de debian comme les autres (toi compris). Le problème a même été remonté sur les listes des devs debian qui s'en sont pris plein sur les doigts. Après, que tu ne me crois pas, ce n'est pas mon problème.
Si c'est sur les listes de développement de Debian, tu dois avoir facilement des pointeurs vers les archives.
Et même si c'est vrai, une boulette de développeurs Debian, ce n'est pas la même chose qu'une politique mauvaise des développeurs du noyau.
J'ai comme l'impression que lenny est une debian stable
Et avant d'être une stable, c'était une testing. À ce moment-là, elle a très bien pu avoir un noyau 2.6.25.
Pascal Hambourg
Nicolas George a écrit :
J'ai comme l'impression que lenny est une debian stable
Et avant d'être une stable, c'était une testing. À ce moment-là, elle a très bien pu avoir un noyau 2.6.25.
Effectivement, en 2008 lenny n'était pas encore stable. Elle a été publiée le 14 février 2009.
Nicolas George a écrit :
J'ai comme l'impression que lenny est une debian stable
Et avant d'être une stable, c'était une testing. À ce moment-là, elle a très
bien pu avoir un noyau 2.6.25.
Effectivement, en 2008 lenny n'était pas encore stable. Elle a été
publiée le 14 février 2009.
J'ai comme l'impression que lenny est une debian stable
Et avant d'être une stable, c'était une testing. À ce moment-là, elle a très bien pu avoir un noyau 2.6.25.
Effectivement, en 2008 lenny n'était pas encore stable. Elle a été publiée le 14 février 2009.
JKB
Le 16-01-2010, ? propos de Re: problème raid, Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
Nicolas George a écrit :
J'ai comme l'impression que lenny est une debian stable
Et avant d'être une stable, c'était une testing. À ce moment-là, elle a très bien pu avoir un noyau 2.6.25.
Effectivement, en 2008 lenny n'était pas encore stable. Elle a été publiée le 14 février 2009.
Je l'ai upgradée à sa sortie, lorsqu'elle a été déclarée stable. D'ailleurs, si elle ne l'était pas, le /etc/issue n'aurait pas été le même.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 16-01-2010, ? propos de
Re: problème raid,
Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
Nicolas George a écrit :
J'ai comme l'impression que lenny est une debian stable
Et avant d'être une stable, c'était une testing. À ce moment-là, elle a très
bien pu avoir un noyau 2.6.25.
Effectivement, en 2008 lenny n'était pas encore stable. Elle a été
publiée le 14 février 2009.
Je l'ai upgradée à sa sortie, lorsqu'elle a été déclarée stable.
D'ailleurs, si elle ne l'était pas, le /etc/issue n'aurait pas été
le même.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 16-01-2010, ? propos de Re: problème raid, Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
Nicolas George a écrit :
J'ai comme l'impression que lenny est une debian stable
Et avant d'être une stable, c'était une testing. À ce moment-là, elle a très bien pu avoir un noyau 2.6.25.
Effectivement, en 2008 lenny n'était pas encore stable. Elle a été publiée le 14 février 2009.
Je l'ai upgradée à sa sortie, lorsqu'elle a été déclarée stable. D'ailleurs, si elle ne l'était pas, le /etc/issue n'aurait pas été le même.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 16-01-2010, ? propos de Re: problème raid, Nicolas George ?crivait dans fr.comp.os.linux.configuration :
JKB wrote in message :
Tout le monde peut faire des boulettes, les devs de debian comme les autres (toi compris). Le problème a même été remonté sur les listes des devs debian qui s'en sont pris plein sur les doigts. Après, que tu ne me crois pas, ce n'est pas mon problème.
Si c'est sur les listes de développement de Debian, tu dois avoir facilement des pointeurs vers les archives.
Tu as ça dans la liste debian-fr et sur les listes anglo-saxonnes. Là, il est plus de minuit et j'ai la flemme de chercher.
Et même si c'est vrai, une boulette de développeurs Debian, ce n'est pas la même chose qu'une politique mauvaise des développeurs du noyau.
Ne change pas le sujet. Lorsqu'un device passe d'un nom à un autre, ça devrait être fait lors du passage d'une version majeure du noyau à une autre. Passer un /dev/hd en /dev/sd au cours d'un patch (parce que le z dans x.y.z, c'est un patch selon les termes du noyau), c'est une immense bêtise.
Et c'est une bêtise indépendamment de la justification technique. C'est un peu comme si ipchain avait été remplacé par iptable entre le 2.6.10 et le 2.6.11 ! C'est exactement la même connerie que ce qui s'est passé entre le 2.4.21 et le 2.4.22 sur sparc, entraînant tout un tas d'incompatibilités et de fonctionnement bizarres, bref, ça ne fait pas sérieux.
Après, tu peux déclarer que les développeurs de debian sont des branques. C'est ton droit le plus strict, mais il ne faut pas perdre de vue qu'ils font en fonction du noyau officiel et qu'ils ne maîtrisent pas forcément ce genre de décision.
J'ai comme l'impression que lenny est une debian stable
Et avant d'être une stable, c'était une testing. À ce moment-là, elle a très bien pu avoir un noyau 2.6.25.
Je l'ai upgradé lors de la sortie _officielle_ de lenny, ce qui est prouvé par le /etc/issue. Le jour où cette lenny a été installée, il y avait un 2.6.25-2 sur les dépots officiels.
<EOT>
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 16-01-2010, ? propos de
Re: problème raid,
Nicolas George ?crivait dans fr.comp.os.linux.configuration :
JKB wrote in message <slrnhl346c.vk0.knatschke@rayleigh.systella.fr>:
Tout le monde peut faire des boulettes, les devs de debian comme les
autres (toi compris). Le problème a même été remonté sur les listes
des devs debian qui s'en sont pris plein sur les doigts. Après, que
tu ne me crois pas, ce n'est pas mon problème.
Si c'est sur les listes de développement de Debian, tu dois avoir facilement
des pointeurs vers les archives.
Tu as ça dans la liste debian-fr et sur les listes anglo-saxonnes.
Là, il est plus de minuit et j'ai la flemme de chercher.
Et même si c'est vrai, une boulette de développeurs Debian, ce n'est pas la
même chose qu'une politique mauvaise des développeurs du noyau.
Ne change pas le sujet. Lorsqu'un device passe d'un nom à un autre,
ça devrait être fait lors du passage d'une version majeure du noyau
à une autre. Passer un /dev/hd en /dev/sd au cours d'un patch (parce
que le z dans x.y.z, c'est un patch selon les termes du noyau), c'est
une immense bêtise.
Et c'est une bêtise indépendamment de la justification technique. C'est
un peu comme si ipchain avait été remplacé par iptable entre le
2.6.10 et le 2.6.11 ! C'est exactement la même connerie que ce qui
s'est passé entre le 2.4.21 et le 2.4.22 sur sparc, entraînant tout
un tas d'incompatibilités et de fonctionnement bizarres, bref, ça ne
fait pas sérieux.
Après, tu peux déclarer que les développeurs de debian sont des
branques. C'est ton droit le plus strict, mais il ne faut pas perdre
de vue qu'ils font en fonction du noyau officiel et qu'ils ne
maîtrisent pas forcément ce genre de décision.
J'ai comme l'impression que lenny est une debian stable
Et avant d'être une stable, c'était une testing. À ce moment-là, elle a très
bien pu avoir un noyau 2.6.25.
Je l'ai upgradé lors de la sortie _officielle_ de lenny, ce qui est
prouvé par le /etc/issue. Le jour où cette lenny a été installée, il
y avait un 2.6.25-2 sur les dépots officiels.
<EOT>
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 16-01-2010, ? propos de Re: problème raid, Nicolas George ?crivait dans fr.comp.os.linux.configuration :
JKB wrote in message :
Tout le monde peut faire des boulettes, les devs de debian comme les autres (toi compris). Le problème a même été remonté sur les listes des devs debian qui s'en sont pris plein sur les doigts. Après, que tu ne me crois pas, ce n'est pas mon problème.
Si c'est sur les listes de développement de Debian, tu dois avoir facilement des pointeurs vers les archives.
Tu as ça dans la liste debian-fr et sur les listes anglo-saxonnes. Là, il est plus de minuit et j'ai la flemme de chercher.
Et même si c'est vrai, une boulette de développeurs Debian, ce n'est pas la même chose qu'une politique mauvaise des développeurs du noyau.
Ne change pas le sujet. Lorsqu'un device passe d'un nom à un autre, ça devrait être fait lors du passage d'une version majeure du noyau à une autre. Passer un /dev/hd en /dev/sd au cours d'un patch (parce que le z dans x.y.z, c'est un patch selon les termes du noyau), c'est une immense bêtise.
Et c'est une bêtise indépendamment de la justification technique. C'est un peu comme si ipchain avait été remplacé par iptable entre le 2.6.10 et le 2.6.11 ! C'est exactement la même connerie que ce qui s'est passé entre le 2.4.21 et le 2.4.22 sur sparc, entraînant tout un tas d'incompatibilités et de fonctionnement bizarres, bref, ça ne fait pas sérieux.
Après, tu peux déclarer que les développeurs de debian sont des branques. C'est ton droit le plus strict, mais il ne faut pas perdre de vue qu'ils font en fonction du noyau officiel et qu'ils ne maîtrisent pas forcément ce genre de décision.
J'ai comme l'impression que lenny est une debian stable
Et avant d'être une stable, c'était une testing. À ce moment-là, elle a très bien pu avoir un noyau 2.6.25.
Je l'ai upgradé lors de la sortie _officielle_ de lenny, ce qui est prouvé par le /etc/issue. Le jour où cette lenny a été installée, il y avait un 2.6.25-2 sur les dépots officiels.
<EOT>
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Fabien LE LEZ
On Sat, 16 Jan 2010 23:27:43 +0000 (UTC), JKB :
Je l'ai upgradée à sa sortie, lorsqu'elle a été déclarée stable.
N'est-ce pas un peu tôt ? J'aurais tendance à attendre, pour installer un logiciel, au moins un mois après qu'il ait été déclaré stable. (Et encore, c'est dans le cas des logiciels "normaux". Pour Firefox, c'est nettement plus long, à cause des extensions pas encore compatibles, et pour Windows, n'en parlons même pas...)
On Sat, 16 Jan 2010 23:27:43 +0000 (UTC), JKB
<knatschke@koenigsberg.fr>:
Je l'ai upgradée à sa sortie, lorsqu'elle a été déclarée stable.
N'est-ce pas un peu tôt ? J'aurais tendance à attendre, pour installer
un logiciel, au moins un mois après qu'il ait été déclaré stable.
(Et encore, c'est dans le cas des logiciels "normaux". Pour Firefox,
c'est nettement plus long, à cause des extensions pas encore
compatibles, et pour Windows, n'en parlons même pas...)
Je l'ai upgradée à sa sortie, lorsqu'elle a été déclarée stable.
N'est-ce pas un peu tôt ? J'aurais tendance à attendre, pour installer un logiciel, au moins un mois après qu'il ait été déclaré stable. (Et encore, c'est dans le cas des logiciels "normaux". Pour Firefox, c'est nettement plus long, à cause des extensions pas encore compatibles, et pour Windows, n'en parlons même pas...)
JKB
Le 16-01-2010, ? propos de Re: problème raid, Fabien LE LEZ ?crivait dans fr.comp.os.linux.configuration :
On Sat, 16 Jan 2010 23:27:43 +0000 (UTC), JKB :
Je l'ai upgradée à sa sortie, lorsqu'elle a été déclarée stable.
N'est-ce pas un peu tôt ? J'aurais tendance à attendre, pour installer un logiciel, au moins un mois après qu'il ait été déclaré stable. (Et encore, c'est dans le cas des logiciels "normaux". Pour Firefox, c'est nettement plus long, à cause des extensions pas encore compatibles, et pour Windows, n'en parlons même pas...)
Si, j'admets. Je n'ai simplement pas vraiment eu le choix. Pour avoir je ne sais plus quelle fonctionnalité dans samba, il me fallait un noyau plus récent que le 2.6.21 et etch avait un 2.6.18. Il me semble que ça tournait autour des verrous posés par Pervasise, et mal gérés avec samba+kernel de etch. Avec etch, je ne pouvais avoir qu'un seul accès sur la base, ce qui posait un tas de problèmes...
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 16-01-2010, ? propos de
Re: problème raid,
Fabien LE LEZ ?crivait dans fr.comp.os.linux.configuration :
On Sat, 16 Jan 2010 23:27:43 +0000 (UTC), JKB
<knatschke@koenigsberg.fr>:
Je l'ai upgradée à sa sortie, lorsqu'elle a été déclarée stable.
N'est-ce pas un peu tôt ? J'aurais tendance à attendre, pour installer
un logiciel, au moins un mois après qu'il ait été déclaré stable.
(Et encore, c'est dans le cas des logiciels "normaux". Pour Firefox,
c'est nettement plus long, à cause des extensions pas encore
compatibles, et pour Windows, n'en parlons même pas...)
Si, j'admets. Je n'ai simplement pas vraiment eu le choix. Pour
avoir je ne sais plus quelle fonctionnalité dans samba, il me
fallait un noyau plus récent que le 2.6.21 et etch avait un 2.6.18.
Il me semble que ça tournait autour des verrous posés par Pervasise,
et mal gérés avec samba+kernel de etch. Avec etch, je ne pouvais
avoir qu'un seul accès sur la base, ce qui posait un tas de
problèmes...
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 16-01-2010, ? propos de Re: problème raid, Fabien LE LEZ ?crivait dans fr.comp.os.linux.configuration :
On Sat, 16 Jan 2010 23:27:43 +0000 (UTC), JKB :
Je l'ai upgradée à sa sortie, lorsqu'elle a été déclarée stable.
N'est-ce pas un peu tôt ? J'aurais tendance à attendre, pour installer un logiciel, au moins un mois après qu'il ait été déclaré stable. (Et encore, c'est dans le cas des logiciels "normaux". Pour Firefox, c'est nettement plus long, à cause des extensions pas encore compatibles, et pour Windows, n'en parlons même pas...)
Si, j'admets. Je n'ai simplement pas vraiment eu le choix. Pour avoir je ne sais plus quelle fonctionnalité dans samba, il me fallait un noyau plus récent que le 2.6.21 et etch avait un 2.6.18. Il me semble que ça tournait autour des verrous posés par Pervasise, et mal gérés avec samba+kernel de etch. Avec etch, je ne pouvais avoir qu'un seul accès sur la base, ce qui posait un tas de problèmes...
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.