probl

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

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.

C'est ça. Continue seulement. Tu as du pot que j'efface
régulièrement mes mirroirs et que je n'ai plus celui de Lenny que
j'avais utilisé à l'époque !

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 ?

Tu es vraiment une caricature de toi-même. Une absence de changement
dans le noyau aurait été à la rigueur de rajouter un nouveau pilote
/dev/sd à la place de /dev/hd, mais en gardant une priorité plus
importante pour l'ancien. Là, il y a un _gros_ changement parce que
par défaut le comportement n'est plus le même. Le reste est une
discussion parfaitement stérile avec quelqu'un qui essaye toujours
d'avoir raison en défendant l'indéfendable. Pire, Microsoft ferait
le même genre de boulette, tu serais le premier à gueuler !

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.

Ce n'est pas n'importe quoi. Tu prouves simplement que tu n'as _pas_
lu ce que j'ai écrit. Je te parle du système de base, pas du
userland. Le système de base, c'est-à-dire /bin, /sbin, /lib et
noyau n'a pas bougé des masses entre etch et lenny, que tu le
veuilles ou non. En ce qui concerne le userland, c'est effectivement
un goufre, mais c'est un autre sujet.

reste entre deux noyaus 2.6.

Cette information est totalement non-pertinente.

Non. On passe d'un 2.6.18 à un 2.6.25 ou 26.

Je n'ai rien à admettre.

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

Comme tu n'admettras jamais avoir tort. Encore une fois, je me
contrefiche de savoir si lenny est sortie avec un 2.6.25 ou 26. Tant
que ça fonctionne, ça m'est parfaitement égal. Il n'y a qu'un type
comme toi pour biaiser. La seule différence entre Tougard et toi,
c'est que tu es juste un peu plus intelligent que lui. Pour le
reste, c'est exactement du même tonneau. Tu fais juste de la
dialectique de bas étage lorsque tu n'as plus rien à dire.

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.

Sans commentaire.

Au passage, je ne cherche pas à te prouver quelque chose. On
pourrait te montrer n'importe quoi, tu trouverais encore à y redire.
Depuis les débuts de Linux, on parle de 'patches against x.y kernel'
lorsqu'on parle du noyau x.y.z ! Si tu lisais les listes de dev du
noyau, tu verrais que tout le monde parle de patches pour le 'z'.

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.

Non. Il devrait y avoir une stabilité minimale de l'API, ce qui
n'est plus le cas avec le 2.6. Et passer d'un 2.6.18 vers un 2.6.25
ou 26 n'est pas une mise à jour majeure. Une mise à jour majeure,
c'est passer d'un 2.4 vers un 2.6. Déclarer que le passage 2.6.18
vers 2.6.25 est une mise à jour majeure signifie simplement que le
noyau est devenue d'une instabilité crasse, ce qu'il n'est pas
encore même s'il en prend la voie.

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

Et alors ?

Ça prouve juste que ton affirmation péremptoire un peu plus haut est
une grosse connerie, mais on n'en est plus là.

Elles t'ont été données.

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

Je t'ai donné un lien sur une page de linuxfr laquelle contient un
fil en français et deux liens juste en haut de la page sur
kerneltrap. Tu ne les as pas lu, mais tu la ramènes quand même.

Fin de la discussion. Tu joues une fois de plus à celui qui veut
avoir la plus grosse. Je te laisse gagner, j'ai un correctif à
envoyer chez NetBSD.

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 17-01-2010, ? propos de
Re: problème raid,
Patrice Karatchentzeff ?crivait dans fr.comp.os.linux.debats :

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.

Ouaips, encore que... Le problème est qu'aujourd'hui tout le monde
teste des versions qui ne sont fiabilisées. Tout le monde se démerde
avec une API qui bouge sans arrêt et qui casse régulièrement les
pilotes les moins utilisés et les architectures un peu exotiques.
Et je ne parle pas des effets de bord comme le remplissage à la
hussarde de l'API 64 bits depuis un userland 32 bits au passage du
2.6.26 au 2.6.27 (de mémoire) qui fait que tout ce qui tournait
entre autre avec la libpcap était cassé, ce qui pose un certain
nombre de problèmes avec des choses comme p0f, knockd et autres !

C'est donc un progrès indéniable. Lorsque tu as un poste de travail
dans ton coin, ce n'est encore pas très gênant. Lorsque tu es obligé
de maintenir des serveurs en terme de sécurité et de disponibilité,
c'est une autre paire de manches, parce que tu as de plus en plus le
choix entre le troué et l'obsolète ou le à jour mais métastable.

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

C'est ça. Continue seulement. Tu as du pot que j'efface
régulièrement mes mirroirs et que je n'ai plus celui de Lenny que
j'avais utilisé à l'époque !

Ouiais, c'est vachement pratique.

Une absence de changement
dans le noyau aurait été à la rigueur de rajouter un nouveau pilote
/dev/sd à la place de /dev/hd,

Ça tombe bien, c'est précisément le cas.

Et c'est con pour toi, parce que ça ruine tout ton discours.

mais en gardant une priorité plus
importante pour l'ancien.

Ça ne veut rien dire puisque, sauf erreur de ma part, les deux drivers sont
mutuellement exclusifs.

Là, il y a un _gros_ changement parce que
par défaut le comportement n'est plus le même.

Il n'y a pas de _par défaut_, il y a le noyau _tel qu'il a été configuré par
la distribution_. Tu ne comprends pas la différence ?

et
noyau n'a pas bougé des masses entre etch et lenny

Ben si, le noyau a énormément changé entre les deux.

Comme tu n'admettras jamais avoir tort.

Pas en face d'une argumentation aussi incohérente que la tienne, ça s'est
sûr.

Depuis les débuts de Linux, on parle de 'patches against x.y kernel'
lorsqu'on parle du noyau x.y.z !

Depuis les débuts de Linux jusqu'au 2.6.8. Après, la méthode de numérotation
a changé.

Et passer d'un 2.6.18 vers un 2.6.25
ou 26 n'est pas une mise à jour majeure.

Si, c'est une mise à jour majeure. C'est comme ça qu'est numéroté le noyau
maintenant. Que ça ne te plaise pas parce que tu n'aimes pas changer tes
habitudes est totalement non-pertinent.

Je t'ai donné un lien sur une page de linuxfr laquelle contient un
fil en français et deux liens juste en haut de la page sur
kerneltrap. Tu ne les as pas lu, mais tu la ramènes quand même.

Je ne lirai pas une référence vague pour essayer d'en sortir des arguments
qui peut-être s'y trouvent ou peut-être pas. Si tu veux prouver quelque
chose, cite des arguments précis.

In article <slrnhl69r5.lie.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:

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,

joker, mais il n'y a pas de raison

plugin java,

Sans problème. http://java.sun.com/j2se/licensees/netbsd.html

plugin flash,

En émulation linux uniquement. Ne fonctionne que sous windowsd CE, windows 98SE,
windows XP+ linux et solaris. Il me semble avoir lu quelque part dans
la licence adobe que c'était interdit d'essayer de l'utiliser sur autre
chose que prévu. En tout cas c'est interdit de l'utiliser surt un PDA qui n'est
pas sous windows CE.)

wifi,

Pareil, pas de raison.

toussa) ?

Tout ce qui serait spécifique à linux fonctionne en mode émulation.

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

L'installation standard ext x11V7 mais sauf changement de dernière minute
ne supporte xrandr. Doug a intérêt à recompiler xorg.

--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer

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

In article <slrnhl69r5.lie.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:

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,

joker, mais il n'y a pas de raison

plugin java,

Sans problème. http://java.sun.com/j2se/licensees/netbsd.html

plugin flash,

En émulation linux uniquement. Ne fonctionne que sous windowsd CE, windows 98SE,
windows XP+ linux et solaris. Il me semble avoir lu quelque part dans
la licence adobe que c'était interdit d'essayer de l'utiliser sur autre
chose que prévu. En tout cas c'est interdit de l'utiliser surt un PDA qui n'est
pas sous windows CE.)

Ouaips, enfin, le plugin flash sous Solaris, c'est juste sous
Solaris x86 et encore, il fonctionne à moitié...

wifi,

Pareil, pas de raison.

toussa) ?

Tout ce qui serait spécifique à linux fonctionne en mode émulation.

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

L'installation standard ext x11V7 mais sauf changement de dernière minute
ne supporte xrandr. Doug a intérêt à recompiler xorg.

Je vais peut-être dire une bêtise, mais j'ai lu dans la doc hier que
sur certaines architectures, Xorg était proposé par défaut. N'étant
pas dans ce cas avec mes sparcs, je n'ai pas testé, mais c'est à
vérifier.

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.

JKB <knatschke@koenigsberg.fr> a écrit :

Ouaips, encore que... Le problème est qu'aujourd'hui tout le
monde teste des versions qui ne sont fiabilisées. Tout le
monde se démerde avec une API qui bouge sans arrêt et qui
casse régulièrement les pilotes les moins utilisés et les
architectures un peu exotiques. Et je ne parle pas des effets
de bord comme le remplissage à la hussarde de l'API 64 bits
depuis un userland 32 bits au passage du 2.6.26 au 2.6.27 (de
mémoire) qui fait que tout ce qui tournait entre autre avec la
libpcap était cassé, ce qui pose un certain nombre de
problèmes avec des choses comme p0f, knockd et autres !

C'est donc un progrès indéniable. Lorsque tu as un poste de
travail dans ton coin, ce n'est encore pas très gênant.
Lorsque tu es obligé de maintenir des serveurs en terme de
sécurité et de disponibilité, c'est une autre paire de
manches, parce que tu as de plus en plus le choix entre le
troué et l'obsolète ou le à jour mais métastable.

Je ne dis pas le contraire : l'ancien système était mieux à mon goût.

D'un autre côté, je n'ai jamais testé non plus un noyau de dév à
l'époque alors je comprends aussi la critique de Linus.

Le système ne tient que si la participation au test des noyaux de dév
est suffisante : manifestement, elle ne l'était pas. Linus a alors
pris une décision comme il sait très bien le faire.

On peut difficilement lui reprocher...

PK

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

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

JKB <knatschke@koenigsberg.fr> a écrit :

Ouaips, encore que... Le problème est qu'aujourd'hui tout le
monde teste des versions qui ne sont fiabilisées. Tout le
monde se démerde avec une API qui bouge sans arrêt et qui
casse régulièrement les pilotes les moins utilisés et les
architectures un peu exotiques. Et je ne parle pas des effets
de bord comme le remplissage à la hussarde de l'API 64 bits
depuis un userland 32 bits au passage du 2.6.26 au 2.6.27 (de
mémoire) qui fait que tout ce qui tournait entre autre avec la
libpcap était cassé, ce qui pose un certain nombre de
problèmes avec des choses comme p0f, knockd et autres !

C'est donc un progrès indéniable. Lorsque tu as un poste de
travail dans ton coin, ce n'est encore pas très gênant.
Lorsque tu es obligé de maintenir des serveurs en terme de
sécurité et de disponibilité, c'est une autre paire de
manches, parce que tu as de plus en plus le choix entre le
troué et l'obsolète ou le à jour mais métastable.

Je ne dis pas le contraire : l'ancien système était mieux à mon goût.

D'un autre côté, je n'ai jamais testé non plus un noyau de dév à
l'époque alors je comprends aussi la critique de Linus.

Pour avoir participé au 2.5, il y avait quand même pas mal de gens
qui testaient le 2.5. L'intérêt d'une branche de développement était
justement d'introduire de grosses modifications sans casser les
machines qui devaient être stables.

Le système ne tient que si la participation au test des noyaux de dév
est suffisante : manifestement, elle ne l'était pas. Linus a alors
pris une décision comme il sait très bien le faire.

On peut difficilement lui reprocher...

Et bien si, on peut le lui reprocher. La décision est à long terme
contre-productive parce qu'il n'y aura pas plus de gens qui
testeront les versions de kernel.org, mais il y aura beaucoup plus
de gens à être dans la panade en raison de gros bugs du noyau qui
devraient absolument être évités. C'est une histoire de qualité.
Il est aussi illusoire de demander aux distributions de stabiliser
les branches du noyau, car il faut patcher dans tous les sens et
suivre les évolutions de la branche principale. C'est un travail qui
devrait être fait en amont.

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 article <slrnhl6n51.lie.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:

Je vais peut-être dire une bêtise, mais j'ai lu dans la doc hier que
sur certaines architectures, Xorg était proposé par défaut.

Pour i386 c'est le cas. Sur sparc aussi il me semble. Xfree86 n'est
plus... et c'est X11R7, c'estait X11R7 quand debian stable était encore
en X11R6.

N'étant
pas dans ce cas avec mes sparcs, je n'ai pas testé, mais c'est à
vérifier.

J'ai fait (il y a quelque temps) une install ssparc 32 et xorg fait
partie du pack standard.

--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer

Le Sun, 17 Jan 2010 17:21:33 +0000, JKB a écrit:

c'est une autre paire de manches, parce que tu as de plus en plus le
choix entre le troué et l'obsolète ou le à jour mais métastable.

Tu as aussi le choix de tourner en version "stable +" 2.6.27, tout
simplement. Ce n'est pas une mauvaise solution, en tout cas pour le
moment c'est celle que j'ai choisie :)

--
The fact that a believer is happier than a sceptic is no more to the
point than the fact that a drunken man is happier than a sober one.
The happiness of credulity is a cheap and dangerous quality.
George Bernard Shaw

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

In article <slrnhl6n51.lie.knatschke@rayleigh.systella.fr>,
JKB <knatschke@koenigsberg.fr> writes:

Je vais peut-être dire une bêtise, mais j'ai lu dans la doc hier que
sur certaines architectures, Xorg était proposé par défaut.

Pour i386 c'est le cas. Sur sparc aussi il me semble.

Sur sparc, c'est X11R7 et non Xorg.

Xfree86 n'est
plus... et c'est X11R7, c'estait X11R7 quand debian stable était encore
en X11R6.

N'étant
pas dans ce cas avec mes sparcs, je n'ai pas testé, mais c'est à
vérifier.

J'ai fait (il y a quelque temps) une install ssparc 32 et xorg fait
partie du pack standard.

Là, tu m'étonnes. J'ai une SS20 qui me sert à débugguer le noyau,
qui est maintenu à jour (NetBSD riemann 5.99.23 NetBSD 5.99.23
(GENERIC.MP)) à grands coups de CVS, et je n'ai pas de Xorg en vue.
Même dans les ports, je n'ai que des paquets xf86*.

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.