probl

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

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.

Le problème est justement le manque de cohérence. La bonne technique
aurait été de garder /dev/hd pour le pilote à jour et un autre nom
pour les anciens pilotes. Il n'y aurait pas eu de problème et madame
Michu n'aurait pas vu sa machine exploser en vol. Là, on s'est
retrouvé avec des noyaux génériques qui compilaient les deux
branches, l'une en /dev/hd et l'autre en /dev/sd avec le pilote
/dev/sd prioritaire sur le /dev/hd et une palanquée et demi de
scripts qui nommaient explicitement des devices /dev/hd alors que
les /dev/sd étaient déjà montés. C'est typiquement un décision prise à la
va vite en dépit du bon sens (ou sans en prendre les conséquences).
Après, que la logique veuille qu'on appelle ces devices /dev/sd
parce qu'ils utilisent les piles SCSI internes, ça se défend. Mais
d'un noyau de la même série à un autre, changer un l'espace de nom
des devices, c'est idiot. Après, on peut toujours rétorquer que
c'est aux distributions de faire le nécessaires, les devs des
distributions ne peuvent penser à tout.

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.

In fr.comp.os.linux.debats JKB <knatschke@koenigsberg.fr> wrote:

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

Pour une fois j'ai bien peur que tu ne sois dans le vrai. FreeBSD fait
comme Linux, et release de nouvelles versions avant que les anciennes ne
soient stabilisées, ce qui revient à la "rolling release" à la Linux.
Je crains qu'ils ne soient obligés de le faire pour ne pas trop se
laisser distancer par Linux, lequel lui même le fait pour essayer de
prendre Windows de vitesse. A son tour Microsoft a sorti un Vista qui
n'était pas du tout prêt pour ne pas se trouver 10 ans en arrière de
Linux. Cet esprit de compétition stupide nous amène à ce que tous les
systèmes d'exploitation sont soit à peu près généralement instables, soit
préhistoriques (genre OpenBSD). Il est possible que NetBSD soit
le meilleur compromis en ce moment, j'entends dire que le fonctionnement
SMP est enfin assez performant. Celà étant, Linux et FreeBSD gardent un
avantage non négligeable, plus de 20000 ports ou équivalent, qui
permettent un usage très généraliste. Je pense aussi que Solaris, Linux
et FreeBSD gardent encore un avantage de performance (bien que réduit)
sur les autres OS.



--

Michel TALON

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

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 _vraiment_ utilisable sur un desktop ça (accélération 3D,
plugin java, plugin flash, wifi, toussa) ?

Ca fait longtemps que j'ai envie de switcher pour BSD mais freeBSD m'a
un poil rebuté.

Pour être précis, avoir à abandonner ses habitudes est un peu hard quand
on connait bien un système.

C'est la principale difficulté pour moi. Dans mes souvenirs, le passage
de Windows à Linux a été moins difficile.

Un truc essentiel pour moi reste quand même une accélération 3D de bon
niveau (équivalente en preformances à ce que propose nvidia sous linux).

Je joue peu mais quand je joue je ne veux pas forcément jouer à
nethack ;-).
Par ex. je "joue" régulièrement à flightgear (simulateur de vol)
qui demande un minimum de perfs pour être agréable et les drivers libres
sous linux (au moins nv et radeon) sont généralement pas assez
performants.

--
@+
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,
Doug713705 ?crivait dans fr.comp.os.linux.debats :

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

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 _vraiment_ utilisable sur un desktop ça (accélération 3D,
plugin java, plugin flash, wifi, toussa) ?

J'ai des trucs comme java dans mon pkgsrc, mais je n'ai pas testé.
Je développement sur une SS20, alors, java ;-) Je ne vois pas
pourquoi tu ne pourrais pas compiler Xorg avec le support 3D
accéléré.

Je viens de jeter un oeil au noyau GENERIC pour amd64 et il y a une
section :

# DRI driver
i915drm* at vga? # Intel i915, i945 DRM driver
mach64drm* at vga? # mach64 (3D Rage Pro, Rage) DRM driver
mgadrm* at vga? # Matrox G[24]00, G[45]50 DRM driver
r128drm* at vga? # ATI Rage 128 DRM driver
radeondrm* at vga? # ATI Radeon DRM driver
savagedrm* at vga? # S3 Savage DRM driver
sisdrm* at vga? # SiS DRM driver
tdfxdrm* at vga? # 3dfx (voodoo) DRM driver

Donc, avec le bon matériel, ça devrait le faire.

Ca fait longtemps que j'ai envie de switcher pour BSD mais freeBSD m'a
un poil rebuté.

Toi aussi ?

Pour être précis, avoir à abandonner ses habitudes est un peu hard quand
on connait bien un système.

C'est la principale difficulté pour moi. Dans mes souvenirs, le passage
de Windows à Linux a été moins difficile.

Un truc essentiel pour moi reste quand même une accélération 3D de bon
niveau (équivalente en preformances à ce que propose nvidia sous linux).

Je joue peu mais quand je joue je ne veux pas forcément jouer à
nethack ;-).
Par ex. je "joue" régulièrement à flightgear (simulateur de vol)
qui demande un minimum de perfs pour être agréable et les drivers libres
sous linux (au moins nv et radeon) sont généralement pas assez
performants.

Radeonhd a fait récemment de gros progrès.

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 <slrnhl664c.lie.knatschke@rayleigh.systella.fr>, a
écrit :

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

ssecem ~ $ ssecem cat /etc/issue
JKB ne sait pas se servir d'un éditeur

<http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.fr.html>

Tu étais censé essayer de prouver qu'il y avait eu un 2.6.25 upgradé en
2.6.26 dans stable. Ce document n'en parle pas.

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) ?

Une mise à jour majeure de la distribution occasionne un changement de nom
de certains périphériques. La belle affaire !

Maintenant, pour les messages des listes de diffusion, tu es assez
grand pour les trouver toi-même.

Je traduis : tu es incapable de les retrouver (parce qu'ils n'existent que
dans ton imagination, probablement ; ou plus précisément parce qu'ils ne
prouvent pas ce que tu prétendais qu'ils prouvent), mais tu ne veux pas
l'admettre.

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.

Et je t'ai déjà répondu au moins deux fois que ça n'avait pas été fait
« entre deux patches.

Ça se conçoit à la limite entre deux versions majeures

Pour le noyau Debian dont tu te plains, c'est précisément le cas.

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.

Effectivement. Ça n'est pas la même chose.

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.

Si tu veux que tes références soient admissibles, donne-les précises.

Je te renvoie parfaitement l'argument.

Si tu veux.

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

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

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

ssecem ~ $ ssecem cat /etc/issue
JKB ne sait pas se servir d'un éditeur

Tu m'expliques ?

<http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.fr.html>

Tu étais censé essayer de prouver qu'il y avait eu un 2.6.25 upgradé en
2.6.26 dans stable. Ce document n'en parle pas.

Je n'ai strictement rien à prouver. Je me contrefiche depuis le
début de savoir si lenny a été déclarée stable avec un 2.6.25 ou un
2.6.26. Je prétends seulement que lorsque j'ai mis à jour etch sur
une machine en lenny/stable, c'est un 2.6.25 qui a été installé.
C'est toi qui veut absolument prouver que lenny n'a été disponible
qu'avec un 2.6.26. Tu veux que je te dises ? Je m'en fiche à un
point que tu n'arrives même pas à imaginer parce que la machine en
question n'est pas accessible sur internet et que sa configuration
est assez scabreuse pour ne pas la toucher une fois qu'elle
fonctionne.

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) ?

Une mise à jour majeure de la distribution occasionne un changement de nom
de certains périphériques. La belle affaire !

C'est toi qui prétend que le changement est mineur et que c'est aux
distributions de contourner le problème. Je te montre que les
distributions ne peuvent pas le faire automatiquement. Qu'on change
le nommage d'une version majeure du noyau à une autre, c'est
nettement plus intelligent parce qu'il y a tout un tas de choses qui
changent par ailleurs. Mettre à jour etch vers lenny, ça devrait
être une _petite_ mise à jour au sens du système de base puisqu'on
reste entre deux noyaus 2.6. Note bien que je ne parle pas du userland,
mais du coeur du système.

Maintenant, pour les messages des listes de diffusion, tu es assez
grand pour les trouver toi-même.

Je traduis : tu es incapable de les retrouver (parce qu'ils n'existent que
dans ton imagination, probablement ; ou plus précisément parce qu'ils ne
prouvent pas ce que tu prétendais qu'ils prouvent), mais tu ne veux pas
l'admettre.

Je n'ai rien à admettre. Je n'archive pas les listes de diffusions
parce que je les lis dans slrn. Tu es assez grand pour chercher.

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.

Et je t'ai déjà répondu au moins deux fois que ça n'avait pas été fait
« entre deux patches.

Si. Passer d'un 2.6.18 à un 2.6.19, c'est un _patch_. C'est ainsi
que Linus les nomme d'ailleurs et c'est aussi ainsi qu'ils
apparaissent sur le ftp de kernel.org. Exemple :

linux-2.6.29.tar.gz patch-2.6.8.gz
linux-2.6.29.tar.gz.sign patch-2.6.8.gz.sign
linux-2.6.29.tar.sign patch-2.6.8.sign
linux-2.6.2.tar.bz2 patch-2.6.9.bz2

Après, qu'il y ait depuis le 2.6.8 des sous-patches, c'est un autre
problème.

Ça se conçoit à la limite entre deux versions majeures

Pour le noyau Debian dont tu te plains, c'est précisément le cas.

Tu confonds une mise à jour de distribution avec une mise à jour
majeure de noyau. C'est aussi ton problème, pas le mien.

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.

Effectivement. Ça n'est pas la même chose.

Et je pourrais te prouver que dans certains cas, les UID de
partition, c'est une immense connerie.

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.

Si tu veux que tes références soient admissibles, donne-les précises.

Elles t'ont été données. Que tu ne veuilles pas les lire, c'est
aussi ton problè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.

> C'est toi qui prétend que le changement est mineur et que
c'est aux distributions de contourner le problème. Je te montre que
les distributions ne peuvent pas le faire automatiquement. Qu'on
change le nommage d'une version majeure du noyau à une autre, c'est
nettement plus intelligent parce qu'il y a tout un tas de
choses qui changent par ailleurs. Mettre à jour etch vers lenny, ça
devrait être une _petite_ mise à jour au sens du système de base
puisqu'on reste entre deux noyaus 2.6. Note bien que je ne parle pas
du userland, mais du coeur du système.

Le problème d'attendre une version majeure du noyau c'est que la
prochaine version majeure (après les 2.6.*) ça semble être Hurd 1.0,
vers 2775.

Après, si j'ai bien compris ce qui s'est dit dans le fil, les anciens
pilotes existent toujours et sont toujours associés aux
noms /dev/hd*, et les nouveaux pilotes sont apparus et sont associés
aux /dev/sd*. Ça me paraît être correct comme procédure de garder les
anciens noms pour les anciens pilotes et les nouveaux pour les
nouveaux pilotes. Sinon tu te retrouves avec un remplacement des
pilotes en conservant les anciens noms et c'est dans le cas où tu
veux continuer à utiliser les anciens pilotes (donc si tu ne veux
rien changer) que tu es obligé de modifier tes scripts. Et par
exemple il me semble que les nouveaux pilotes ne fonctionnent (ou ne
fonctionnaient ?) pas avec de (vraiment) vieux disques.

Ensuite au niveau de la distribution ils peuvent choisir de privilégier
les nouveaux pilotes, mais c'est à eux de ne pas changer en cours de
version stable (donc de ne faire cette modif qu'en passant à la
nouvelle version stable).
Peut-être même qu'ils peuvent bricoler udev (?) pour que les deux noms
coexistent ?

Tiens, une question au passage : pourquoi les clés usb sont-elles
nommées sd* ? Parce que tout ça utilise des pilotes partiellement
communs ? Un jour je me suis demandé si le module SCSI du noyau était
obligatoire pour pouvoir accéder aux clés usb, à cause de ce nommag e.

Doug713705 <doug.letough@free.fr> 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é.

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

Dixit Linus, c'était parce que personne ne testait les versions
impaires.

PK

--
      |      _,,,---,,_       Patrice KARATCHENTZEFF
ZZZzz /,`.-'`'    -.  ;-;;,_   mailto:p.karatchentzeff@free.fr
     |,4-  ) )-,_. , (  `'-'  http://p.karatchentzeff.free.fr
    '---''(_/--'  `-'_)       

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

Je prétends seulement que lorsque j'ai mis à jour etch sur
une machine en lenny/stable, c'est un 2.6.25 qui a été installé.

Eh bien c'est la preuve que tu fais n'importe quoi avec tes upgrades, parce
qu'avec une utilisation normale, ce n'est juste pas possible. Il n'y a pas
de 2.6.25 dans Lenny depuis qu'elle est stable, ça ne va pas plus loin.

Qu'on change
le nommage d'une version majeure du noyau à une autre, c'est

Pour la dernière fois, il n'y a pas eu de _changement_ dans le noyau. Quand
vas-tu te le mettre dans la tête ?

Mettre à jour etch vers lenny, ça devrait
être une _petite_ mise à jour

N'importe quoi. C'est une mise à jour de version majeure du système, avec
des sorties espacées de près de deux ans.

reste entre deux noyaus 2.6.

Cette information est totalement non-pertinente.

Je n'ai rien à admettre.

Tu n'admettras surtout pas que tu as dit des conneries.

linux-2.6.29.tar.gz patch-2.6.8.gz
linux-2.6.29.tar.gz.sign patch-2.6.8.gz.sign
linux-2.6.29.tar.sign patch-2.6.8.sign
linux-2.6.2.tar.bz2 patch-2.6.9.bz2

man diff ; ça ne prouve strictement rien, on peut faire un patch qui passe
du 1.0.0 au 2.6.30 directement.

Tu confonds une mise à jour de distribution avec une mise à jour
majeure de noyau. C'est aussi ton problème, pas le mien.

Si tu installes ton noyau par la distribution, l'un implique l'autre. Une
mise à jour majeure de la distribution implique une mise à jour majeure du
noyau, quel que soit le numéro de version.

Et je pourrais te prouver que dans certains cas, les UID de
partition, c'est une immense connerie.

Et alors ?

Elles t'ont été données.

Voici la preuve absolue que tu as tort : http://www.google.com/ : il te
suffit de lire.

Après mûre réflexion, JKB a écrit :

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

Mmhmmm, tout est dit...

X'est aujourd'hui une course toujours plus rapide à
l'ajout de nouvelles fonctionnalités au détriment de la stabilité
d'ensemble.

Tiens, tiens tiens

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.

Hoo

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 !

On mets ca sur un serveur ?

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.).

Mmm

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.

Et bien quel courage après tout ce temps...

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

Merci pour ce témoignage digne d'intérêt

--
P4nd1-P4nd4 vous salue, et annonce que le petit ourson possède
désormais son blog
p4nd1-p4nd4.over-blog.com