En passant, je veux aussi dire que je ne suis pas contre la coopération entre les distributions.
Bien évidemment.
Mais un "état major" qui fixe ce qu'un ensemble de distribution de faire : c'est non.
> comme indiqué au haut de mon post Pour parler d'un sujet que je connais, Mandriva
OK, désolé.
Mais ça ne reste toujours pas claire.
Que pointes-tu ?
Un manque de moyen ?
Des conflits dans les rôles ?
Je comprend mal.
> Fedora 8 en est au 2.6.23.1 d'après distrowatch.
Distrowatch est une bonne source d'info. Mais pas toujours exacte.
Actuellement pour F8 c'est un 2.6.24.7 (mise à jour du 14/05).
Je ne sais pas si un 2.6.25 est prévu. Mais il ne faudra pas être surpris s'il y en a un. S'il n'y a pas encore de 2.6.25, j'image que c'est à cause d'un manque de moyen (ou d'autres priorités, ou une meilleure opportunité qui se présentera un peu plus tard, etc).
> Fedora 9, 2.6.25 contre 2.6.25.4 et rawhide d'ailleurs 2.6.25.2.
> Pour les weak-updates, je n'ai pas trop compris c'est dans le paquet kernel de Fedora ?
C'est /sbin/weak-modules (un script sh) qui le fait (appelé par les scripts d'installation du rpm kernel). /sbin/weak-modules est dans module-init-tools.
Mais, tel est Fedora, bourré de surprise :-)
L'appel à weak-modules est mis en commentaire depuis peu de temps .
J'ignore précisément les raisons.
Je n'ai trouvé que ça comme info : http://www.redhat.com/archives/rhl-devel-list/2007-March/msg(...)
FWIW, weak-modules will go away in a future Fedora. The plan is to replace it with a much more comprehensive online driver update tool that will do a lot more than just create symlinks - more information when I have an example to share... :-)
> Désolé de dire ça, mais en sécurité informatique, il FAUT être paranoiaque.
Et c'est toi qui le dit...
Ben Debian ne devrait pas être autorisé n'importe qui à patcher OpenSSL...
Il ne faut pas utiliser Debian/Ubuntu/etc.
Debian ne devrait pas utiliser Debian.
Etc.
Faire de la paranoïa la règle absolue est stupide et contre productif.
Il est d'autant plus marrant que tu dises "il FAUT être paranoiaque" alors que manifestement Debian ne l'a pas été et que tu n'arrêtes de chercher des excuses au mainteneur qui a fait la boulette alors qu'il ne l'a pas été non plus (et que tu ne trouves pas ça grave...).
> J'ai dit que je m'attendais à voir un rebond de Mandriva
Oui, j'assume ma prédiction et la remet ici.
Je n'attend pas que mes prédictions soient confirmer pour "au moment opportun" dire "je vous l'avais dit".
> J'ai en fait un peu l'impression que la stabilisation proposée par Andrew Morton (les .1, .2, .3) est sous-utilisée et que les distributions n'arrivent pas à "accrocher" sur le travail d'intégration qui était censé leur échoir.
Tu peux sourcer ?
Donne des cas précis.
Parce qu'en fait, j'ai l'impression que tu n'as pas d'argument pour critiquer le processus (ou l'organisation). Tu es seulement déçu. Je veux bien l'entendre, mais ce n'est pas à mon avis suffisant pour remettre en cause le processus et son application.
Puis tu sembles totalement faire l'impasse sur les distributions qui ne montent pas en version de noyau et font des backports (RHEL, SLES, etc les distributions "entreprise"). Pour ces dernières, ça marche exactement comme le dit Andrew Morton.
> Un cas précis que j'ai en tête est le pilote wifi ipw3945, iwl3945, iwlwifi :
Dans ce domaine, la distribution Fedora fait une grosse contribution (les noyaux ont toujours les derniers patchs wifi ; normal c'est un employé Red Hat qui maintient wifi).
> - les "iwl" s'appuient sur la nouvelle pile wifi pas complètement terminée, l'un dans le noyau, une version plus récente en dkms[2]
Et ?
La priorité de l'upstream est mise sur ce qui va marcher, pas sur ce qui ne marchera jamais bien. Ça me semble très normal.
> - Mandriva a en fait proposé les 3 pilotes, sous forme de dkms (avec la pile wifi qui fonctionne avec chaque version)
C'est le boulot de Mandriva (vu sa cible). Ce n'est pas le boulot d'autres distributions.
Tu as peut-être mal compris Andrew Morton. Il n'a pas dit que les distributions on tobligation de faire ce que fait Mandriva. Il a voulu dire que l'upstream sera plus concentré sur le développement que de fournir un noyau directement utilisable par les distributions. Les distributions doivent donc s'attendre à fournir du boulot et non seulement piquer le noyau sur http://www.kernel.org/ . Une distribution peu bloquer la sortie d'une nouvelle version s'il y a un driver très utilisé qui sucks. Le noyau vanilla ne le fera pas (ou beaucoup moins).
> Tout l'intérêt de dkms est de "gentoo-ifier" les modules
Ce n'est pas toujours vraiment intéressant (or pour voir si la recompilation marche).
Fedora a un système pour "récupérer" les modules de l'ancien noyau qui ne sont pas dans le nouveau lors de la mise à jours. Ceci est fait si l'API utiliser par le module n'a pas changée.
On retrouve ses modules dans /lib/modules/`uname -r `/weak-updates après la mise à jour.
NB: pour Fedora dkms n'est pas très intéressant puisque Fedora a souvent la dernier version du noyau. Donc si le système "weak-updates" ne marche pas, il faut très probablement des nouveaux sources pour le module et donc repackager le module (pas seulement le recompiler).
Je crains que les choses sont plus compliquées.
Il y a les distributions communautaires qui veulent être très proche de l'upstream (Fedora, Gentoo, etc). Les mi-communautaire / mi-commerciale qui mette leur plus value à une version du noyau (pilote avec ancienne pile wifi, etc) pour la satisfaction de leurs clients. Ces dernières ont une mission "produit" plus marquée.
Il y a les distributions presque exclusivement commerciale : RHEL, SLES, etc.
De quoi tu parles ? :-)
> Cela peut se comprendre ainsi, en forçant le trait :
J'ai admis qu'il y a avait peut-être (voire manifestement) une erreur de formulation.
J'ai clairement, il me semble, rectifié ce que je voulais dire.
Je m'excuse encore de m'être mal exprimé.
Par pitié, ne parlez pas de mauvaise fois, lorsque je veux dire quelque chose je le dis.
> Si tu as voulu dire le b), bin tu t'es mal exprimé, tu peux l'assumer hein.
http://linuxfr.org/comments/931937,1.html
Je ne suis pas de mauvaise fois. Quand je veux dire un truc, je le dis sans détour.
J'ai aucune information sur le partenariat entre Mandriva et TurboLinux et ce depuis des mois.
Et ici personne en a donné réellement.(*) Donc j'ai aucun avis si ça a réussi ou non.
(*) : c'était vrai au moment du post.
> tu peux l'assumer hein.
Très bien, j'assume avoir mal formulé, j'ai corrigé déjà une fois, je veux bien le refaire. J'ai aucun problème à reconnaitre mes erreurs. J'ai aussi beaucoup de respect pour ceux qui reconnaissent leur erreur il est donc normal que je reconnaisse les miennes.
Mais ce que je n'ai pas voulu dire, je n'ai pas voulu le dire. Point barre !
> tu peux l'assumer hein.
J'assume parfaitement ma mauvaise prédiction.
Si tu veux te foutre de moi car ma prédiction était fausse, fait le.
Je ne te critiquerai pas dans la "mamoeuvre", même si évidemment je n'apprécierai pas ça.
M'enfin, j'assume ma mauvaise prédiction.
Par contre, je ne m'excuserai pas sur ma mauvaise prédiction. Ce n'était qu'une prédiction.
> Ton chahutage de boklm est ce qui me fait dire que tu sautes bien vite aux conclusions,
Quelle conclusion ?
A toi d'assumer, puisque ça fait deux fois que tu parles de conclusion, où as-tu vu que je faisais une conclusion sur le deal Mandriva et TurboLinux ?
Assume : cherche et trouve !
Assume : si tu ne trouves pas, excuse toi.
> tu vas même au plafond ;-)
J'ai horreur qu'on me prête des propos que je n'ai pas tenu.
Je comprend bien qu'on puisse faire des erreurs (moi, toi, tout le monde).
Mais arrête de dire (comme encore un fois ici) que j'ai fait une conclusion sur le deal entre Mandriva et TurboLinux.
En passant, prêter des propos à une personne alors qu'elle ne les a pas tenu est de la diffamation. Ne t'inquiète pas, je ne vais pas t'attaquer en justice pour ça. Mais merde, c'est grave !
> Tu n'as pas d'élément, mais tu n'oublies pas de rappeler ton avis de l'époque
J'ai déjà dit que je n'avais aucun élément. Merci (ça doit être la troisième fois que le dit...) d'avoir apporté des éléments.
Et alors ?
J'assume mon avis de l'époque.
Lorsque j'ai écrit "on a déjà vue des tentatives qui ont bien foiré. La dernière, et dans une moindre mesure, est Mandriva avec TurboLinux (où en est ce truc ?)", oui je m'attendais à ce que le deal entre Mandriva et TurboLinux ait foiré. Je m'y attendais. Ma pensée était aussi sur ma prédiction. Je n'ai aucun problème de le reconnaitre. Mais ce n'est pas une conclusion sur le deal entre Mandriva et TurboLinux (Diantre, il y avait où en est ce truc ?).
> tu n'oublies pas de rappeler ton avis de l'époque (des fois qu'on aurait oublié de te le demander, alors qu'en fait il ne t'a effectivement pas été demandé
Je vais te le dire tout net :
- je t'emmerde, je dis ce que je veux. Je n'attend pas ta demande, ni aucune demande.
> mais tu fais très bien les questions et les réponses donc ça va ;-) ).
Tu fais très mal les conclusion des autres.
Juste en passant, quand Mandriva 2008.1 est sortie avec FF 2 (NB: Ubuntu 8.04 n'était pas sorti) il y eu des critiques pour dire que Mandriva aurait dû sorti avec FF 3.
J'ai dit que je trouvais normal que Mandriva 2008.1 utilise FF2.
Mais ça évident tu n'as remarqué. Tu fais une lecture sélective et après ne rate pas une occasion de chier une pendule.
J'ai dit plus d'une fois que je préfère l'époque post-Duval de Mandriva à l'époque Duval.
Mais ça encore une fois tu oublies.
J'ai dit que je m'attendais à voir un rebond de Mandriva car Mandriva fait, il me semble, globalement un bon boulot aujourd'hui.
Mais ça encore une fois tu oublies.
Si tu as la moindre information sur un regain de forme de Mandriva, donne les. N'hésite pas une seconde.
Si c'est l'inverse et que ma prédiction est fausse, donne les infos, fous toi de ma gueule.
Ce sont des informations sur des fais, elles sont toujours les bienvenues.
Pourtant, si j'étais aussi diabolique que tu veux le faire croire, pour justifier qu'on m'insulter de mauvaise fois, etc, pourquoi tu ne dis rien lorsque je dis quelque chose de positif sur Mandriva ?
Mais non rien. Ce qui est normal en fait. Mais ce qui n'est pas normal c'est de venir systématiquement me chercher des poux dans la tête.
Il y a eu "fiasco SSL" et certain disait "je vais passer à Fedora" d'autres disait "je vais passer à Mandriva". À ces derniers je n'ai pas dit "tant qu'à changer de distribution, passez à Fedora". Pourquoi diable je n'ai pas fait ça alors que je suis diabolique de mauvaise fois, et gnagnagna et gnagnagna ?
On peut le dire.
Mais si on cherche des limites dans la FSF (et la GPL) qui "tolère" du proprio (ou y ressemblant), on en trouve beaucoup.
La FSF tolère qu'un programme libre soit exécuté sur un OS proprio.
La FSF tolère les "sharewares" lorsque que ce ne sont que des données.
Etc.
Es-ce mal ?
Ce n'est pas évident. On ne va pas dire que c'est mal d'utiliser FF sur Windows :-)
> je crains que ton expérience de la Vraie Vie se cantonne encore à un monde plein de poneys roses avec une crinière argentée et une étoile sur le derrière.
Fait une fixation sur les architectures si tu veux.
Mais c'est le nombre d'architecture, le fait d'avoir stable/testing/unstable/backport/que-sais-je-encore , de maintenir des patchs en local au-lieux de les envoyer en upstream, de vouloir sa propre branche Firefox, etc.
> mais en interne les mainteneurs utilisent git et tous les patches sont correctement séparés dans la version distribuée sur git.debian.org.
Ce n'est pas le cas, et de loins : http://blog.orebokech.com/2008/05/some-diffgz-statistics.htm(...)
One of the issues under discussion is that some Debian packages don't use a patch system and ship all their modifications unseparated in the Debian .diff.gz, which makes it harder or impossible to extract patches later on and to understand why some changes were made.
...
Out of curiosity, I did a quick scan of my local mirror to see how many packages ship changes outside debian/ in their .diff.gz, and I was surprised to see that 4803 source packages out of 11853 (40%) do so!
> Dans ce cas, si je trouve une faille critique, je la renvoie à Mandriva, mais en privé, pour leur laisser le temps de régler le soucis sans mettre en danger tout le monde
Notons aussi que les distributions, lorsqu'il y a une faille de sécurité, informent cert-vendor. Donc toutes les distributions sont au courant (en privé) si c'est un problème upstream. Elles sont toutes dans le même bateau si tu envoyes le rapport de bug à "seulement" Mandriva. Ce rapport de bug, même qu'à une distribution, est suffisant et apprécié de tous.
Je trouve ceci vraiment excellent (mais c'est aussi le moindre) de voir que les distributions ne se tirent pas dans les pattes lorsqu'il sagit de sécurité.
> bin tu sautes rapidement aux conclusions... sans élément factuel.
ARRÊTEZ DE DIRE CE QUE JE N'AI PAS DIT !!!
Je n'ai jamais conclu que c'était un échec !
Où j'ai dit ça ? J'ai dit que je n'en savait rien ! J'ai dit que je n'en savait rien !
Où tu vois une conclusion ?
Maintenant, merci pour les informations que tu nous donnes. Elles indiquent que ma PRÉDICTION (et non conclusion) de l'échec de la collaboration entre Mandriva et TurboLinux était fausse.
> et ne te doit pas de comptes ou d'explications
ARRÊTEZ DE DIRE CE QUE JE N'AI PAS DIT !!!
Merde, je peux dire des trucs sur des choses même si ces dernières n'ont pas de compte à me rendre.
J'ai jamais demandé à Mandriva où autre de rendre des comptes sur la collaboration entre Mandriva et TurboLinux.
Sûr que tu as critiqué MS-OOXML, pourtant MS-OOXML n'a pas de compte à te rendre (à moins que tu ais payé MS pour MS-OOXML...).
> Il y en aura plus de dit le moment utile àmha, par exemple quand TurboLinux sortira sa propre version.
N'hésites surtout à nous tenir informé [1]. Tu peux dire que ma PRÉDICTION était fausse et te foutre de moi. Mais n'invente pas une conclusion que je n'aurais jamais faite.
[1] : Ceci ne te demande pas de me rendre des comptes, c'est seulement une invitation à nous tenir informer. Tu peux évidemment te torcher le cul de cette invitation.
La FSF n'empêche pas exécuter un programme libre sur un OS proprio.
C'est du "Et puis quoi encore..." pour toi ?
La FSF n'impose pas qu'un source soit compilable uniquement avec du logiciel libre (Avant gcj/icedtea/openjdk, tu pouvais parfaitement faire des programmes libre en java).
C'est du "Et puis quoi encore..." pour toi ?
> les questions à se poser tout de même par rapport aux blobs fournis dans le kernel, avant de les virer maladivement sont:
Tu parles de blobs. Mais il y a deux types de blob. Ceux exécutés par le noyau (ou l'OS de façon plus large) et les blob qui sont chargés sur un périphérique et exécuté par le périphérique. Pour ce dernier cas, c'est un firmware.
Même en tant que "libriste", j'ai très peu de problème avec les blob-firmware. Pour moi l'OS est libre (tout proprio que soit le hardware et les périphériques qui utilisent des firmwares chargés par le noyau). Mais la distribution ?
Il y a problème pour la distribution. Le problème se pose lorsque, par exemple, tu conseilles une distribution et dis qu'elle est libre (ce qui veut dire que TOUS les sources (y compris les firmwares) sont disponibles). Ben s'il y a un blob-firmware, elle n'est pas libre. Donc il y a tromperie sur la marchandise. C'est emmerdant car c'est moche d'utilise le mot "libre" pour manifestement quelque chose qui ne l'est pas (je n'évalue pas le problème, je dis seulement qu'il y a problème).
> - est-ce qu'il existe réellement un code source...
Si le firmware n'est pas vraiment un blob (par exemple le développeur utilise un éditeur hexa (ça arrive) et il y a la doc), il n'y a pas de problème.
Mais il y a des vrais blog-firmware (qui sont aussi dans Linux vanilla). C'est ici que le problème ce pose (où commence).
La tendance globale (mais non ferme) que je perçois est qu'il faut que ce problème soit pris en compte en upstream. Attention, je ne dis pas que l'upstream va virer les blobs. Mais l'upstream doit faire le nécessaire pour permettre de facilement faire des versions de Linux sans blob. Ceci étant maintenu par l'upstream. Après c'est aux distributions de décider si elles veulent ou non intégrer les blob-firmware.
> - dans le cas où un code source existerait, est-il possible de mettre en œuvre une chaine de compilation pour ces éléments sans faire exploser la complexité de la compilation du noyau?
Je ne vois pas où tu veux en venir. On ne va pas demander au noyau de compiler le firmware. On veut qu'il y ait les sources. On n'interdit pas l'existance du blob (qui peut-être compilé ailleurs).
Ou F8 pour ppc/ppc64 qui n'est pas sorti avec IcedTea (contrairement à i386/x86_64).
C'est très bien les gens qui font des efforts pour supporter une architecture. C'est très très respectable. Mais bloquer tout le reste (98 % des utilisateurs) à cause d'une architecture...
> Est-ce que l'upstream va intégrer cette "fonctionnalité" ?
Aucune idée.
Je trouve ça con d'intégrer cette "fonctionnalité" et en même ça a un côté necéssaire.
Aucune idée.
> Cette "fonctionnalité" a t'elle un intérêt hormis tenter de limiter la prolifération de clé faible Debian ?
La prolifération des clés faibles Debian/etc est un problème de sécurité. Donc ça doit être upstream. Mais c'est con de mettre cette fonctionnalité en upstream.
Aucune idée (je l'ai déjà dit je crois :-)).
Tu réponds à un commentaire :
- "il faudrait penser au fait qu'annoncer publiquement dès le zéro day n'apporte rien d'autre qu'une augmentation du danger si l'éditeur s'occupe généralement de règler les failles."
Puis toi :
- "ça c'est quand l'éditeur dit qu'il va la corriger"
Si la faille n'est pas public, il ne dit qu'il va la corriger. Par définition, ce n'est pas public.
> parce que dans la vraie vie, c'est pas toujours ça.
C'est par rapport à quoi ?
Par rapport au commentaire auquel tu réponds ?
Le cas des éditeurs qui ne s'occupent pas de règler les failles, le commentaire auquel tu réponds n'en parle pas.
Tu changes de sujet, voire les mélange, alors forcément on peut se prendre les pieds dans le tapis.
"La vraie vie" ne se résume à généraliser la caricature que tu as faite.
La vraie vie c'est aussi plein d'éditeur qui font correctement leur boulot.
> le raisonement n'est juste que pour les taches qui prennent 100% de temps CPU pendant un laps de temps
Lorsqu'une tache a du boulot et que le noyau lui passe la main, le boulot est fait à 100 % du CPU. Jamais 50 ou 25 %. Toujours 100 %. Et la tache ne passe jamais à 25 % ou 0 %, la tache passe la main au noyau lorsqu'elle a finie (ou est en attende d'une ressource, etc).
C'est simple, un tache qui a le cpu (ou un coeur) l'a totalement à 100 %. Il ne l'a pas à 30 %, il ne peut pas décider d'utiliser que 25 % du cpu, etc. C'est 100 % et que 100 %.
En moyenne une tache peut bouffer 25 % du cpu. Mais ça veut dire que durant 25 % du temps la tache à 100 % du cpu, et le reste du temps la tache n'a tout simplement pas le cpu.
> En fait, il est assez rare que ma machine ait besoin de monter à sa fréquence maximale
Ceci l'OS ne peut pas le décider. L'OS ne va pas décider que compiler un noyau en 3 heures est satisfaisant et utiliser "25 % du cpu". L'OS a une tache à faire, il la fait le plus vite possible. Toujours.
Et il a pris la licence GPL v2...
Et en plus il tient à ce qu'elle soit respectée (sauf pour certaines API (modules), c'est un flou sur l'interprétation de travail dérivé).
Linus Torvalds ne n'en fout pas de savoir si c'est libre ou non.
Pas contre, il ne veut pas participer à l'action "politique" de Stallman.
Stallman veut "améliorer le monde" (pour simplifier), et ça Linus s'en fout. Mais il veut que son noyau reste libre.
Il n'a pas pris la GPL pour rien.
C'est l'un des drames de la faille Debian, toutes les autres distributions vont avoir besoin de cette "feature" (de merde).
MS va te dire qu'un anti-virus est une feature. La vrai feature est d'avoir un OS qui n'a pas besoin d'anti-virus.
Une connerie (un OS virus friendly) créé une "feature" => les anti-virus.
C'est pareil pour la connerie de Debian.
[^] # Re: synchro ou suivre ou avancer
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
Bien évidemment.
Mais un "état major" qui fixe ce qu'un ensemble de distribution de faire : c'est non.
[^] # Re: synchro ou suivre ou avancer
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
OK, désolé.
Mais ça ne reste toujours pas claire.
Que pointes-tu ?
Un manque de moyen ?
Des conflits dans les rôles ?
Je comprend mal.
> Fedora 8 en est au 2.6.23.1 d'après distrowatch.
Distrowatch est une bonne source d'info. Mais pas toujours exacte.
Actuellement pour F8 c'est un 2.6.24.7 (mise à jour du 14/05).
Je ne sais pas si un 2.6.25 est prévu. Mais il ne faudra pas être surpris s'il y en a un. S'il n'y a pas encore de 2.6.25, j'image que c'est à cause d'un manque de moyen (ou d'autres priorités, ou une meilleure opportunité qui se présentera un peu plus tard, etc).
> Fedora 9, 2.6.25 contre 2.6.25.4 et rawhide d'ailleurs 2.6.25.2.
Ce n'est que temporaire. Il y a évidemment un délais entre les releases upstream et Fedora.
Le 2.6.25.3 est dans les mise à jours (de F9).
Le 2.6.25.4 est en préparation :
http://koji.fedoraproject.org/koji/buildinfo?buildID=49409
> Pour les weak-updates, je n'ai pas trop compris c'est dans le paquet kernel de Fedora ?
C'est /sbin/weak-modules (un script sh) qui le fait (appelé par les scripts d'installation du rpm kernel). /sbin/weak-modules est dans module-init-tools.
Mais, tel est Fedora, bourré de surprise :-)
L'appel à weak-modules est mis en commentaire depuis peu de temps .
J'ignore précisément les raisons.
Je n'ai trouvé que ça comme info :
http://www.redhat.com/archives/rhl-devel-list/2007-March/msg(...)
FWIW, weak-modules will go away in a future Fedora. The plan is to replace it with a much more comprehensive online driver update tool that will do a lot more than just create symlinks - more information when I have an example to share... :-)
[^] # Re: Une réaction sur Debian Planet en français
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 1.
Automatiser ?
...
[^] # Re: Merci pour cette information.
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
Donc elles n'ont à être validé par la FSF.
[^] # Re: Mise en perspéctive
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 1.
Et c'est toi qui le dit...
Ben Debian ne devrait pas être autorisé n'importe qui à patcher OpenSSL...
Il ne faut pas utiliser Debian/Ubuntu/etc.
Debian ne devrait pas utiliser Debian.
Etc.
Faire de la paranoïa la règle absolue est stupide et contre productif.
Il est d'autant plus marrant que tu dises "il FAUT être paranoiaque" alors que manifestement Debian ne l'a pas été et que tu n'arrêtes de chercher des excuses au mainteneur qui a fait la boulette alors qu'il ne l'a pas été non plus (et que tu ne trouves pas ça grave...).
[^] # Re: toujours cette maladie...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
Je n'ai jamais dit que tous posaient problème.
Ce n'est pas car certains ne pose pas problème, qu'il faut ignorer ceux qui posent problème.
Tu parles d'autre chose.
Je n'ai pas envi d'entrer dans ces histoires ou on coupe les cheveux en quatre.
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
Oui, j'assume ma prédiction et la remet ici.
Je n'attend pas que mes prédictions soient confirmer pour "au moment opportun" dire "je vous l'avais dit".
[^] # Re: synchro ou suivre ou avancer
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
Tu peux sourcer ?
Donne des cas précis.
Parce qu'en fait, j'ai l'impression que tu n'as pas d'argument pour critiquer le processus (ou l'organisation). Tu es seulement déçu. Je veux bien l'entendre, mais ce n'est pas à mon avis suffisant pour remettre en cause le processus et son application.
Puis tu sembles totalement faire l'impasse sur les distributions qui ne montent pas en version de noyau et font des backports (RHEL, SLES, etc les distributions "entreprise"). Pour ces dernières, ça marche exactement comme le dit Andrew Morton.
> Un cas précis que j'ai en tête est le pilote wifi ipw3945, iwl3945, iwlwifi :
Dans ce domaine, la distribution Fedora fait une grosse contribution (les noyaux ont toujours les derniers patchs wifi ; normal c'est un employé Red Hat qui maintient wifi).
> - les "iwl" s'appuient sur la nouvelle pile wifi pas complètement terminée, l'un dans le noyau, une version plus récente en dkms[2]
Et ?
La priorité de l'upstream est mise sur ce qui va marcher, pas sur ce qui ne marchera jamais bien. Ça me semble très normal.
> - Mandriva a en fait proposé les 3 pilotes, sous forme de dkms (avec la pile wifi qui fonctionne avec chaque version)
C'est le boulot de Mandriva (vu sa cible). Ce n'est pas le boulot d'autres distributions.
Tu as peut-être mal compris Andrew Morton. Il n'a pas dit que les distributions on tobligation de faire ce que fait Mandriva. Il a voulu dire que l'upstream sera plus concentré sur le développement que de fournir un noyau directement utilisable par les distributions. Les distributions doivent donc s'attendre à fournir du boulot et non seulement piquer le noyau sur http://www.kernel.org/ . Une distribution peu bloquer la sortie d'une nouvelle version s'il y a un driver très utilisé qui sucks. Le noyau vanilla ne le fera pas (ou beaucoup moins).
> Tout l'intérêt de dkms est de "gentoo-ifier" les modules
Ce n'est pas toujours vraiment intéressant (or pour voir si la recompilation marche).
Fedora a un système pour "récupérer" les modules de l'ancien noyau qui ne sont pas dans le nouveau lors de la mise à jours. Ceci est fait si l'API utiliser par le module n'a pas changée.
On retrouve ses modules dans /lib/modules/`uname -r `/weak-updates après la mise à jour.
NB: pour Fedora dkms n'est pas très intéressant puisque Fedora a souvent la dernier version du noyau. Donc si le système "weak-updates" ne marche pas, il faut très probablement des nouveaux sources pour le module et donc repackager le module (pas seulement le recompiler).
Je crains que les choses sont plus compliquées.
Il y a les distributions communautaires qui veulent être très proche de l'upstream (Fedora, Gentoo, etc). Les mi-communautaire / mi-commerciale qui mette leur plus value à une version du noyau (pilote avec ancienne pile wifi, etc) pour la satisfaction de leurs clients. Ces dernières ont une mission "produit" plus marquée.
Il y a les distributions presque exclusivement commerciale : RHEL, SLES, etc.
De quoi tu parles ? :-)
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
J'ai admis qu'il y a avait peut-être (voire manifestement) une erreur de formulation.
J'ai clairement, il me semble, rectifié ce que je voulais dire.
Je m'excuse encore de m'être mal exprimé.
Par pitié, ne parlez pas de mauvaise fois, lorsque je veux dire quelque chose je le dis.
> Si tu as voulu dire le b), bin tu t'es mal exprimé, tu peux l'assumer hein.
http://linuxfr.org/comments/931937,1.html
Je ne suis pas de mauvaise fois. Quand je veux dire un truc, je le dis sans détour.
J'ai aucune information sur le partenariat entre Mandriva et TurboLinux et ce depuis des mois.
Et ici personne en a donné réellement.(*)
Donc j'ai aucun avis si ça a réussi ou non.
(*) : c'était vrai au moment du post.
> tu peux l'assumer hein.
Très bien, j'assume avoir mal formulé, j'ai corrigé déjà une fois, je veux bien le refaire. J'ai aucun problème à reconnaitre mes erreurs. J'ai aussi beaucoup de respect pour ceux qui reconnaissent leur erreur il est donc normal que je reconnaisse les miennes.
Mais ce que je n'ai pas voulu dire, je n'ai pas voulu le dire. Point barre !
> tu peux l'assumer hein.
J'assume parfaitement ma mauvaise prédiction.
Si tu veux te foutre de moi car ma prédiction était fausse, fait le.
Je ne te critiquerai pas dans la "mamoeuvre", même si évidemment je n'apprécierai pas ça.
M'enfin, j'assume ma mauvaise prédiction.
Par contre, je ne m'excuserai pas sur ma mauvaise prédiction. Ce n'était qu'une prédiction.
> Ton chahutage de boklm est ce qui me fait dire que tu sautes bien vite aux conclusions,
Quelle conclusion ?
A toi d'assumer, puisque ça fait deux fois que tu parles de conclusion, où as-tu vu que je faisais une conclusion sur le deal Mandriva et TurboLinux ?
Assume : cherche et trouve !
Assume : si tu ne trouves pas, excuse toi.
> tu vas même au plafond ;-)
J'ai horreur qu'on me prête des propos que je n'ai pas tenu.
Je comprend bien qu'on puisse faire des erreurs (moi, toi, tout le monde).
Mais arrête de dire (comme encore un fois ici) que j'ai fait une conclusion sur le deal entre Mandriva et TurboLinux.
En passant, prêter des propos à une personne alors qu'elle ne les a pas tenu est de la diffamation. Ne t'inquiète pas, je ne vais pas t'attaquer en justice pour ça. Mais merde, c'est grave !
> Tu n'as pas d'élément, mais tu n'oublies pas de rappeler ton avis de l'époque
J'ai déjà dit que je n'avais aucun élément. Merci (ça doit être la troisième fois que le dit...) d'avoir apporté des éléments.
Et alors ?
J'assume mon avis de l'époque.
Lorsque j'ai écrit "on a déjà vue des tentatives qui ont bien foiré. La dernière, et dans une moindre mesure, est Mandriva avec TurboLinux (où en est ce truc ?)", oui je m'attendais à ce que le deal entre Mandriva et TurboLinux ait foiré. Je m'y attendais. Ma pensée était aussi sur ma prédiction. Je n'ai aucun problème de le reconnaitre. Mais ce n'est pas une conclusion sur le deal entre Mandriva et TurboLinux (Diantre, il y avait où en est ce truc ?).
> tu n'oublies pas de rappeler ton avis de l'époque (des fois qu'on aurait oublié de te le demander, alors qu'en fait il ne t'a effectivement pas été demandé
Je vais te le dire tout net :
- je t'emmerde, je dis ce que je veux. Je n'attend pas ta demande, ni aucune demande.
> mais tu fais très bien les questions et les réponses donc ça va ;-) ).
Tu fais très mal les conclusion des autres.
Juste en passant, quand Mandriva 2008.1 est sortie avec FF 2 (NB: Ubuntu 8.04 n'était pas sorti) il y eu des critiques pour dire que Mandriva aurait dû sorti avec FF 3.
J'ai dit que je trouvais normal que Mandriva 2008.1 utilise FF2.
Mais ça évident tu n'as remarqué. Tu fais une lecture sélective et après ne rate pas une occasion de chier une pendule.
J'ai dit plus d'une fois que je préfère l'époque post-Duval de Mandriva à l'époque Duval.
Mais ça encore une fois tu oublies.
J'ai dit que je m'attendais à voir un rebond de Mandriva car Mandriva fait, il me semble, globalement un bon boulot aujourd'hui.
Mais ça encore une fois tu oublies.
Si tu as la moindre information sur un regain de forme de Mandriva, donne les. N'hésite pas une seconde.
Si c'est l'inverse et que ma prédiction est fausse, donne les infos, fous toi de ma gueule.
Ce sont des informations sur des fais, elles sont toujours les bienvenues.
Pourtant, si j'étais aussi diabolique que tu veux le faire croire, pour justifier qu'on m'insulter de mauvaise fois, etc, pourquoi tu ne dis rien lorsque je dis quelque chose de positif sur Mandriva ?
Mais non rien. Ce qui est normal en fait. Mais ce qui n'est pas normal c'est de venir systématiquement me chercher des poux dans la tête.
Il y a eu "fiasco SSL" et certain disait "je vais passer à Fedora" d'autres disait "je vais passer à Mandriva". À ces derniers je n'ai pas dit "tant qu'à changer de distribution, passez à Fedora". Pourquoi diable je n'ai pas fait ça alors que je suis diabolique de mauvaise fois, et gnagnagna et gnagnagna ?
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
On peut le dire.
Mais si on cherche des limites dans la FSF (et la GPL) qui "tolère" du proprio (ou y ressemblant), on en trouve beaucoup.
La FSF tolère qu'un programme libre soit exécuté sur un OS proprio.
La FSF tolère les "sharewares" lorsque que ce ne sont que des données.
Etc.
Es-ce mal ?
Ce n'est pas évident. On ne va pas dire que c'est mal d'utiliser FF sur Windows :-)
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
Ce sont des données, ce n'est pas exécuté par un cpu.
> Je trouve ca un peu bizarre de voulloir absolument retirer tous les firmware non libres
C'est du code (binaire), c'est un programme exécuté sur un cpu.
[^] # Re: Mise en perspéctive
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à -2.
Pas toi ?
C'est triste.
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 0.
Mais c'est le nombre d'architecture, le fait d'avoir stable/testing/unstable/backport/que-sais-je-encore , de maintenir des patchs en local au-lieux de les envoyer en upstream, de vouloir sa propre branche Firefox, etc.
C'est un problème globale.
[^] # Re: Limite du développement bénévole
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 2.
Ce n'est pas le cas, et de loins :
http://blog.orebokech.com/2008/05/some-diffgz-statistics.htm(...)
One of the issues under discussion is that some Debian packages don't use a patch system and ship all their modifications unseparated in the Debian .diff.gz, which makes it harder or impossible to extract patches later on and to understand why some changes were made.
...
Out of curiosity, I did a quick scan of my local mirror to see how many packages ship changes outside debian/ in their .diff.gz, and I was surprised to see that 4803 source packages out of 11853 (40%) do so!
[^] # Re: Mise en perspéctive
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 4.
Notons aussi que les distributions, lorsqu'il y a une faille de sécurité, informent cert-vendor. Donc toutes les distributions sont au courant (en privé) si c'est un problème upstream. Elles sont toutes dans le même bateau si tu envoyes le rapport de bug à "seulement" Mandriva. Ce rapport de bug, même qu'à une distribution, est suffisant et apprécié de tous.
Je trouve ceci vraiment excellent (mais c'est aussi le moindre) de voir que les distributions ne se tirent pas dans les pattes lorsqu'il sagit de sécurité.
[^] # Re: La réponse d'Aaron Seigo
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 1.
ARRÊTEZ DE DIRE CE QUE JE N'AI PAS DIT !!!
Je n'ai jamais conclu que c'était un échec !
Où j'ai dit ça ?
J'ai dit que je n'en savait rien !
J'ai dit que je n'en savait rien !
Où tu vois une conclusion ?
Maintenant, merci pour les informations que tu nous donnes. Elles indiquent que ma PRÉDICTION (et non conclusion) de l'échec de la collaboration entre Mandriva et TurboLinux était fausse.
> et ne te doit pas de comptes ou d'explications
ARRÊTEZ DE DIRE CE QUE JE N'AI PAS DIT !!!
Merde, je peux dire des trucs sur des choses même si ces dernières n'ont pas de compte à me rendre.
J'ai jamais demandé à Mandriva où autre de rendre des comptes sur la collaboration entre Mandriva et TurboLinux.
Sûr que tu as critiqué MS-OOXML, pourtant MS-OOXML n'a pas de compte à te rendre (à moins que tu ais payé MS pour MS-OOXML...).
> Il y en aura plus de dit le moment utile àmha, par exemple quand TurboLinux sortira sa propre version.
N'hésites surtout à nous tenir informé [1]. Tu peux dire que ma PRÉDICTION était fausse et te foutre de moi. Mais n'invente pas une conclusion que je n'aurais jamais faite.
[1] : Ceci ne te demande pas de me rendre des comptes, c'est seulement une invitation à nous tenir informer. Tu peux évidemment te torcher le cul de cette invitation.
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 2.
La FSF n'empêche pas exécuter un programme libre sur un OS proprio.
C'est du "Et puis quoi encore..." pour toi ?
La FSF n'impose pas qu'un source soit compilable uniquement avec du logiciel libre (Avant gcj/icedtea/openjdk, tu pouvais parfaitement faire des programmes libre en java).
C'est du "Et puis quoi encore..." pour toi ?
[^] # Re: toujours cette maladie...
Posté par IsNotGood . En réponse au journal FSF et distributions. Évalué à 4.
Tu parles de blobs. Mais il y a deux types de blob. Ceux exécutés par le noyau (ou l'OS de façon plus large) et les blob qui sont chargés sur un périphérique et exécuté par le périphérique. Pour ce dernier cas, c'est un firmware.
Même en tant que "libriste", j'ai très peu de problème avec les blob-firmware. Pour moi l'OS est libre (tout proprio que soit le hardware et les périphériques qui utilisent des firmwares chargés par le noyau). Mais la distribution ?
Il y a problème pour la distribution. Le problème se pose lorsque, par exemple, tu conseilles une distribution et dis qu'elle est libre (ce qui veut dire que TOUS les sources (y compris les firmwares) sont disponibles). Ben s'il y a un blob-firmware, elle n'est pas libre. Donc il y a tromperie sur la marchandise. C'est emmerdant car c'est moche d'utilise le mot "libre" pour manifestement quelque chose qui ne l'est pas (je n'évalue pas le problème, je dis seulement qu'il y a problème).
> - est-ce qu'il existe réellement un code source...
Si le firmware n'est pas vraiment un blob (par exemple le développeur utilise un éditeur hexa (ça arrive) et il y a la doc), il n'y a pas de problème.
Mais il y a des vrais blog-firmware (qui sont aussi dans Linux vanilla). C'est ici que le problème ce pose (où commence).
Il y a ici un long thread sur ce problème :
http://www.redhat.com/archives/fedora-devel-list/2008-March/(...)
La tendance globale (mais non ferme) que je perçois est qu'il faut que ce problème soit pris en compte en upstream. Attention, je ne dis pas que l'upstream va virer les blobs. Mais l'upstream doit faire le nécessaire pour permettre de facilement faire des versions de Linux sans blob. Ceci étant maintenu par l'upstream. Après c'est aux distributions de décider si elles veulent ou non intégrer les blob-firmware.
> - dans le cas où un code source existerait, est-il possible de mettre en œuvre une chaine de compilation pour ces éléments sans faire exploser la complexité de la compilation du noyau?
Je ne vois pas où tu veux en venir. On ne va pas demander au noyau de compiler le firmware. On veut qu'il y ait les sources. On n'interdit pas l'existance du blob (qui peut-être compilé ailleurs).
[^] # Re: Mesures qui seront prises ?
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 2.
C'est très bien les gens qui font des efforts pour supporter une architecture. C'est très très respectable. Mais bloquer tout le reste (98 % des utilisateurs) à cause d'une architecture...
[^] # Re: Feature ! blink blink !!
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 2.
Aucune idée.
Je trouve ça con d'intégrer cette "fonctionnalité" et en même ça a un côté necéssaire.
Aucune idée.
> Cette "fonctionnalité" a t'elle un intérêt hormis tenter de limiter la prolifération de clé faible Debian ?
La prolifération des clés faibles Debian/etc est un problème de sécurité. Donc ça doit être upstream. Mais c'est con de mettre cette fonctionnalité en upstream.
Aucune idée (je l'ai déjà dit je crois :-)).
[^] # Re: Mise en perspéctive
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 2.
- "il faudrait penser au fait qu'annoncer publiquement dès le zéro day n'apporte rien d'autre qu'une augmentation du danger si l'éditeur s'occupe généralement de règler les failles."
Puis toi :
- "ça c'est quand l'éditeur dit qu'il va la corriger"
Si la faille n'est pas public, il ne dit qu'il va la corriger. Par définition, ce n'est pas public.
> parce que dans la vraie vie, c'est pas toujours ça.
C'est par rapport à quoi ?
Par rapport au commentaire auquel tu réponds ?
Le cas des éditeurs qui ne s'occupent pas de règler les failles, le commentaire auquel tu réponds n'en parle pas.
Tu changes de sujet, voire les mélange, alors forcément on peut se prendre les pieds dans le tapis.
"La vraie vie" ne se résume à généraliser la caricature que tu as faite.
La vraie vie c'est aussi plein d'éditeur qui font correctement leur boulot.
[^] # Re: Un bon test
Posté par IsNotGood . En réponse à la dépêche Gestion de l'énergie : se dépêcher de ne rien faire. Évalué à 2.
À toi de voir.
[^] # Re: pas convaincu.
Posté par IsNotGood . En réponse à la dépêche Gestion de l'énergie : se dépêcher de ne rien faire. Évalué à 4.
Lorsqu'une tache a du boulot et que le noyau lui passe la main, le boulot est fait à 100 % du CPU. Jamais 50 ou 25 %. Toujours 100 %. Et la tache ne passe jamais à 25 % ou 0 %, la tache passe la main au noyau lorsqu'elle a finie (ou est en attende d'une ressource, etc).
C'est simple, un tache qui a le cpu (ou un coeur) l'a totalement à 100 %. Il ne l'a pas à 30 %, il ne peut pas décider d'utiliser que 25 % du cpu, etc. C'est 100 % et que 100 %.
En moyenne une tache peut bouffer 25 % du cpu. Mais ça veut dire que durant 25 % du temps la tache à 100 % du cpu, et le reste du temps la tache n'a tout simplement pas le cpu.
> En fait, il est assez rare que ma machine ait besoin de monter à sa fréquence maximale
Ceci l'OS ne peut pas le décider. L'OS ne va pas décider que compiler un noyau en 3 heures est satisfaisant et utiliser "25 % du cpu". L'OS a une tache à faire, il la fait le plus vite possible. Toujours.
[^] # Re: L'éthique à l'heure du numérique
Posté par IsNotGood . En réponse au journal Sur la philosophie de M. Stallman. Évalué à 5.
Et il a pris la licence GPL v2...
Et en plus il tient à ce qu'elle soit respectée (sauf pour certaines API (modules), c'est un flou sur l'interprétation de travail dérivé).
Linus Torvalds ne n'en fout pas de savoir si c'est libre ou non.
Pas contre, il ne veut pas participer à l'action "politique" de Stallman.
Stallman veut "améliorer le monde" (pour simplifier), et ça Linus s'en fout. Mais il veut que son noyau reste libre.
Il n'a pas pris la GPL pour rien.
[^] # Re: Feature ! blink blink !!
Posté par IsNotGood . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 4.
MS va te dire qu'un anti-virus est une feature. La vrai feature est d'avoir un OS qui n'a pas besoin d'anti-virus.
Une connerie (un OS virus friendly) créé une "feature" => les anti-virus.
C'est pareil pour la connerie de Debian.