probl

JKB wrote in message <slrnhl4ja4.lie.knatschke@rayleigh.systella.fr>:

Ne change pas le sujet.

Au contraire, je ramenais la discussion à son sujet initial.

Lorsqu'un device passe d'un nom à un autre,
ça devrait être fait lors du passage d'une version majeure du noyau
à une autre.

Le changement de hd à sd pour les disques IDE n'est pas une question de
version du noyau, c'est une question de configuration. Tu peux les avoir en
sd sur un 2.6.18 comme tu peux les avoir en hd sur un 2.6.30.

parce
que le z dans x.y.z, c'est un patch selon les termes du noyau

D'autre part, non, c'est faux. Les patch, c'est le passage de 2.6.x à
2.6.x.1.

Je l'ai upgradé lors de la sortie _officielle_ de lenny

Tout le monde peut faire des boulettes, toi compris.

Le 17-01-2010, ? propos de
Re: problème raid,
Nicolas George ?crivait dans fr.comp.os.linux.configuration :

JKB wrote in message <slrnhl4ja4.lie.knatschke@rayleigh.systella.fr>:

Ne change pas le sujet.

Au contraire, je ramenais la discussion à son sujet initial.

Lorsqu'un device passe d'un nom à un autre,
ça devrait être fait lors du passage d'une version majeure du noyau
à une autre.

Le changement de hd à sd pour les disques IDE n'est pas une question de
version du noyau, c'est une question de configuration. Tu peux les avoir en
sd sur un 2.6.18 comme tu peux les avoir en hd sur un 2.6.30.

Tu le fais exprès ? Je parle de noyau compilé _par défaut_ dans une
distribution. Je parle de problème que peut avoir madame Michu. Ce
problème, lorque je l'ai eu , il m'a fallu dix seconde pour
comprendre !

parce
que le z dans x.y.z, c'est un patch selon les termes du noyau

D'autre part, non, c'est faux. Les patch, c'est le passage de 2.6.x à
2.6.x.1.

http://linuxfr.org/2005/03/08/18449.html

Si tu appelles ça autrement qu'un patch, j'aimerais que tu me
définisses le mot. Après, tu vas rétorquer que, comme maintenant, on
numérote x.y.z.t, le patch c'est t et plus z. Historiquement, z est
le z-ième patch du noyau x.y que tu le veuilles ou non. Le t a été
rajouté uniquement parce que le processus de développement est
devenu absurde.

Je l'ai upgradé lors de la sortie _officielle_ de lenny

Tout le monde peut faire des boulettes, toi compris.

Tu n'as pas un peu l'impression que tu es l'hôpital qui se fout de
la charité ?

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 wrote in message <slrnhl5jj6.lie.knatschke@rayleigh.systella.fr>:

Tu le fais exprès ? Je parle de noyau compilé _par défaut_ dans une
distribution.

Alors tu dois regarder le numéro de version de la distribution, par le
numéro de version du noyau. Ce n'est pas ce que tu as fait jusqu'à présent,
donc tu argumentation ne vaut rien.

http://linuxfr.org/2005/03/08/18449.html

Super la référence.

rajouté uniquement parce que le processus de développement est
devenu absurde.

Tu te tougardifies à vue d'oeil.

Le 17-01-2010, ? propos de
Re: problème raid,
Nicolas George ?crivait dans fr.comp.os.linux.configuration :

JKB wrote in message <slrnhl5jj6.lie.knatschke@rayleigh.systella.fr>:

Tu le fais exprès ? Je parle de noyau compilé _par défaut_ dans une
distribution.

Alors tu dois regarder le numéro de version de la distribution, par le
numéro de version du noyau. Ce n'est pas ce que tu as fait jusqu'à présent,
donc tu argumentation ne vaut rien.

Debian Lenny, c'est un numéro de distribution, la 5.0. Cette
distribution avait au moment où j'ai fait le dist-upgrade un noyau
2.6.25-2. Le /etc/issue prouve que le dist-upgrade a été fait
lorsqu'elle était stable (j'ai admis que c'était juste après cette
déclaration et je t'ai même dit pourquoi). Que ce noyau ait été
remplacé par un 2.6.26 pour une raison ou une autre n'entre pas en
ligne de compte ici. Je ne vais surtout pas me battre pour savoir si
le noyau 2.6.25 et le noyau officiel de Lenny ou si c'est maintenant
un 2.6.26.

Un peu plus haut, tu disais qu'il fallait utiliser les UID de
partition. Je n'utilise _jamais_ ce truc parce que j'ai des scripts
qui utilisent /dev/xxx et aussi parce que le système de boot sur uid
de partition n'est _pas_ portable. Bref, ça marche bien lorsqu'on a un
PC, ça marche nettement moins bien ailleurs (voire ça fait
directement des erreurs sur les disklabels Sun lorsque tu utilises
ça sur le premier cylindre du disque...).

http://linuxfr.org/2005/03/08/18449.html

Super la référence.

Tu as en haut une référence à un fil sur kerneltrap initié par
Linus. Lis-le attentivement. Je ne connais pas de référence plus
directe qu'un fil de discussion initié par Linus. Que tu ne veuille
pas le lire est un autre débat.

rajouté uniquement parce que le processus de développement est
devenu absurde.

Tu te tougardifies à vue d'oeil.

Toi, tu ne changes pas, tu veux toujours avoir raison. De toute
façon, venant de toi, c'est presque un compliment.

Prouve-moi simplement que le développement du noyau n'est pas devenu
aberrant. C'est aujourd'hui une course toujours plus rapide à
l'ajout de nouvelles fonctionnalités au détriment de la stabilité
d'ensemble. Les devices changent, certaines verrues ont été
rajoutées pour que le même device apparaissent sous _deux_ noms avec
le _même_ pilote (je te laisse chercher), la seule architecture où
le noyau est vraiment testé est l'architecture PC 32 et 64 bits, le
reste est plus ou moins à l'abandon. Je me demande même par moment
comment les types de debian arrivent encore à sortir autant de
distributions stables sur l'ensemble des architectures supportées
officiellement par debian... J'ai des Mac historiquement
sous Linux, je traîne des vieux noyaux parce que les récents soit ne
bootent pas, soit ne sont pas stables. Le noyau sparc64 n'arrive
pas à suivre les patches, les sous-patches et les modifications de
tout poil. C'est même pour ça que j'ai arrêté de soumettre des
patches pour le sparc32, j'ai trop de mal à suivre les
développements du sparc64 pour m'occuper en plus des bugs
d'interruption et de watchdog reset du sparc 32 ! On traîne entre autres
une aberration totale dans la gestion des spinlocks et du handcheck
depuis longtemps (en gros le 2.6.18), aberration qui fait
que le raid soft sur sparc peut s'endormir durant plusieurs minutes,
voire forcer un redémarrage de la machine, et personne n'arrive à corriger
la chose parce que les fonctions de base du noyau changent plus vite
que leur ombre entre deux patches successifs de la branche 2.6 !
Je ne te parle même pas des patches comme ceux du iSCSI qui sont
stables, mais pas inclus dans le noyau (alors que d'autres sont
plantogènes mais inclus officiellement, va comprendre).
Idem pour l'alpha. Le sparc32 est aux choux depuis le 2.6
dès qu'il s'agit de le faire tourner sur autre chose que du sun4m UP
(et encore, il ne faut surtout pas sortir un HyperSparc, parce que
lui, depuis la version 2.4, sa gestion du cache est foirée et il ne
_fonctionne_ plus.).

Tout ça pour dire que je fais partie des premiers utilisateurs de
Linux, ma première machine en production ayant tourné avec un noyau
1.0.9, ça ne nous rajeunit pas. J'étais satisfait du chemin que
prenait Linux jusqu'au 2.6.8, mais que le chemin que prend
actuellement le noyau me semble est celui d'une vaste rigolade,
puisque jamais, on ne fiabilise vraiment l'existant. On rajoute des
trucs, ça oui, mais sans que les fondements soient vraiment stables.
C'est même pour ça qu'on se retrouve aujourd'hui avec un noyau
2.6.27 ayant été déclaré 'long term'. Forcément, du 2.6.28 au
2.6.31, on a cassé un tas de choses, dont le fonctionnement en
userland mixte 32/64 bits, les verrous, certaines parties du NFS et
j'en passe tout en déclarant ces noyaux stables. Certains noyaux ne
bootent même plus sur sparc64/US-IIICu, le dernier étant un 2.6.28.10.
Ce genre de chose ne s'est _jamais_ vu avec le mécanisme de
développement de la branche 2.4.

Je tiens _exactement_ le même discours à l'encontre de FreeBSD,
surtout depuis la version 8, parce que j'ai l'affreuse impression
que le mode de développement (voire le but ultime) est 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 , dans le message <slrnhl60is.lie.knatschke@rayleigh.systella.fr>, a
écrit :

Debian Lenny, c'est un numéro de distribution, la 5.0. Cette
distribution avait au moment où j'ai fait le dist-upgrade un noyau
2.6.25-2. Le /etc/issue prouve que le dist-upgrade a été fait
lorsqu'elle était stable

Non, /etc/issue ne prouve strictement rien.

J'attends encore les références à ces hypothétiques messages sur la
mailing-list prouvant qu'il y a bien eu une erreur dans l'upgrade du noyau.

Et en supposant que tu arrives à les trouver, j'attends la preuve que cette
erreur est de la responsabilité des développeurs noyau, comme tu l'as
prétendu.

Un peu plus haut, tu disais qu'il fallait utiliser les UID de
partition.

Non, je n'ai pas dit ça. Apprends à lire.

j'ai des scripts

Et quelques messages plus haut tu prétendais te placer du point de vue d'un
utilisateur de base.

Tu as en haut une référence à un fil sur kerneltrap initié par
Linus.

Tu as donné une référence linuxfr, pas kerneltrap.

Prouve-moi simplement que le développement du noyau n'est pas devenu
aberrant.

Tu m'excuseras d'avoir plus de respect envers les compétences techniques de
Linus qu'envers les tiennes.

Dans fr.comp.os.linux.configuration,fr.comp.os.linux.debats JKB nous
expliquait:

Ce genre de chose ne s'est _jamais_ vu avec le mécanisme de
développement de la branche 2.4.

Bah oui, je n'ai jamais vraiment compris pourquoi le systèmes des 2
branches parallèles (numéro de version paire/impaire) a été abandonné.

Ca garantissait une meilleure la stabilité et la robustesse qui ont fait
la réputation de Linux.

Il vrai qu'aujourd'hui le noyau évolue plus vite qu'avant mais
quel est l'intérêt d'intégrer au plus vite des drivers buggués ?

Si c'est pour dire "regardez, nous aussi on sait faire", c'est dommage.

Ceci dit, avec un peu de chance, une partie des devs noyau
indépendants vont finir par en avoir marre et les efforts pourraient
être reportés sur le Hurd qui n'attend que ça ;-)

D'ailleurs, à part le manque de matière grise et de main d'oeuvre,
qu'est ce qui fait que le développement du Hurd soit si long (si tant
est qu'il avance !) ?

c'est une vraie question.
--
@+
Doug - Linux user #307925 - Slackware64 roulaize ;-)
[ Plus ou moins avec une chance de peut-être ]

Le 17-01-2010, ? propos de
Re: problème raid,
Nicolas George ?crivait dans fr.comp.os.linux.debats :

JKB , dans le message <slrnhl60is.lie.knatschke@rayleigh.systella.fr>, a
écrit :

Debian Lenny, c'est un numéro de distribution, la 5.0. Cette
distribution avait au moment où j'ai fait le dist-upgrade un noyau
2.6.25-2. Le /etc/issue prouve que le dist-upgrade a été fait
lorsqu'elle était stable

Non, /etc/issue ne prouve strictement rien.

Et bien si. Lorsque une debian passe en stable, son /etc/issue
devient un truc avec un numéro. Si elle est testing ou unstable sont
/etc/issue est :

cauchy:[~] > cat /etc/issue
Debian GNU/Linux squeeze/sid n l

Cette machine ayant été installée en etch puis upgradée _une_ seule
fois en lenny, le dist-upgrade a été fait sur une lenny stable.

J'attends encore les références à ces hypothétiques messages sur la
mailing-list prouvant qu'il y a bien eu une erreur dans l'upgrade du noyau.

<http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.fr.html>
avec le point 4.8. Tellement de gens ont gueulé que ce point a été
rajouté dans la doc. S'il n'y avait pas eu de problème, crois-tu que
la doc aurait été modifiée en conséquence (qui plus est en français) ?
Maintenant, pour les messages des listes de diffusion, tu es assez
grand pour les trouver toi-même.

Et en supposant que tu arrives à les trouver, j'attends la preuve que cette
erreur est de la responsabilité des développeurs noyau, comme tu l'as
prétendu.

J'ai juste dit que changer /dev/hd en /dev/sd est une connerie des
développeurs du noyau qui n'avait rien à faire entre deux patches.
Ça se conçoit à la limite entre deux versions majeures, mais pas au
fil de l'eau comme ça a été fait. Je t'ai dit aussi que le fait de
modifier le fonctionnement _interne_ du noyau (passer le pilote IDE en
émulation SCSI) n'avait rien à voir avec le nommage du device et
qu'on aurait tout à fait pu avoir un /dev/hd qui utilisait le
nouveau sous-système en renommant l'ancien /dev/oldhda pour ce que
tu veux. On aurait ainsi évité toute cette pagaille.

Un peu plus haut, tu disais qu'il fallait utiliser les UID de
partition.

Non, je n'ai pas dit ça. Apprends à lire.

Si, tu as dit un peu plus haut que si tout le monde utilisait les
UID de partition à la place des devices, il n'y aurait pas eu de
problème.

j'ai des scripts

Et quelques messages plus haut tu prétendais te placer du point de vue d'un
utilisateur de base.

Exactement. Je n'ai _pas_ eu le problème (enfin, si, mais ça ma pris
10 secondes pour comprendre d'où venait le problème). J'ai
simplement écrit que pour l'utilisateur de base, voir une mise à
jour qui te détruit ton système, c'est franchement contre-productif.

Tu as en haut une référence à un fil sur kerneltrap initié par
Linus.

Tu as donné une référence linuxfr, pas kerneltrap.

Tu te fous de moi ? La référence était effectivement un lien vers
linuxfr, mais avec en gros tout en haut, la référence de deux fils
de kerneltrap.

Prouve-moi simplement que le développement du noyau n'est pas devenu
aberrant.

Tu m'excuseras d'avoir plus de respect envers les compétences techniques de
Linus qu'envers les tiennes.

Je te renvoie parfaitement l'argument. Faire de la pseudo
dialectique à deux balles, tu sais faire. C'est même la seule chose
que tu sais faire. D'ailleurs, pourquoi ne réponds-tu pas sur les
problèmes d'utilisation des UID hors du monde du PC ? N'aurais-tu
rien à dire ?

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 Sun, 17 Jan 2010 14:07:55 +0100, Doug713705 a écrit:

Bah oui, je n'ai jamais vraiment compris pourquoi le systèmes des 2
branches parallèles (numéro de version paire/impaire) a été abandonné.

En fait il a repris d'une façon un peu différente puisqu'il y a une
branche super-stable : le 2.6.27.

--
The question of whether computers can think is just like the question of
whether submarines can swim.
Edsger W. Dijkstra

Le Sun, 17 Jan 2010 14:02:51 +0000, JKB a écrit:

J'ai juste dit que changer /dev/hd en /dev/sd est une connerie des
développeurs du noyau qui n'avait rien à faire entre deux patches.

Ah non, là c'est différent : il y a deux séries de drivers ATA, l'ancien
système avec les "/dev/hdXX", et le nouveau. Les deux séries coexistent
dans le noyau, on peut choisir de compiler l'une, l'autre ou les deux.
Dans le cas où les deux sont activées en modules, je pense que udev prend
ceux qui sont en SCSI par défaut.

--
Toutes les organisations ont leur règles, et les Femmes Algériennes
doivent avoir aussi leurs règles.
Kaid Ahmed.

Le 17-01-2010, ? propos de
Re: problème raid,
Doug713705 ?crivait dans fr.comp.os.linux.debats :

Dans fr.comp.os.linux.configuration,fr.comp.os.linux.debats JKB nous
expliquait:

Ce genre de chose ne s'est _jamais_ vu avec le mécanisme de
développement de la branche 2.4.

Bah oui, je n'ai jamais vraiment compris pourquoi le systèmes des 2
branches parallèles (numéro de version paire/impaire) a été abandonné.

Moi non plus, mais NG va certainement nous l'expliquer. Enfin si,
pour avoir suivi la discussion, j'ai ma petite idée...

Ca garantissait une meilleure la stabilité et la robustesse qui ont fait
la réputation de Linux.

Il vrai qu'aujourd'hui le noyau évolue plus vite qu'avant mais
quel est l'intérêt d'intégrer au plus vite des drivers buggués ?

C'est exactement ça. J'ai même l'impression que le but est de
fournit juste un noyau à jour pour les x86 et que pour les autres,
c'est du vieux parce qu'on n'a pas trop le temps de suivre. C'est
vraiment dommage. D'ailleurs même sur amd64, il y a des tas de
problèmes bloquants dans le noyau au moins jusqu'au 2.6.30.x qui
entrait dans un dead lock lorsqu'on montait en charge avec un swap
sollicité. Pas vraiment propre, un windows des familles faisait
mieux, c'est dire !

Si c'est pour dire "regardez, nous aussi on sait faire", c'est dommage.

Ceci dit, avec un peu de chance, une partie des devs noyau
indépendants vont finir par en avoir marre et les efforts pourraient
être reportés sur le Hurd qui n'attend que ça ;-)

J'ai eu des discussions privées avec David Miller qui commence aussi
à en avoir marre; Les problèmes de réseau récent sont de sont fait
parce qu'il n'a même plus le temps de tester à fond ses patches.
Quant au support sparc dont il est officiellement responsable, des
tas de patches sont passés à l'aveugle allant du oops au panic.
Les contrôleurs SCSI (esp) doivent fonctionner en mode dégradé pour
ne pas faire de oops, sur l'U1, le contrôleur merdoie dès qu'il est
sollicité pour faire du raid1... C'est tout ce qu'on veut sauf
sérieux. Linux est encore utilisé parce que c'est toujours mieux que
Windows, mais le système s'est salement dégradé depuis quelque
temps.

D'ailleurs, à part le manque de matière grise et de main d'oeuvre,
qu'est ce qui fait que le développement du Hurd soit si long (si tant
est qu'il avance !) ?

Je préférerais qu'ils aillent vers NetBSD ;-)

c'est une vraie question.

La voie n'est peut-être pas la bonne (performances, portabilité...).

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.