Lui faire gentiment remarquer que tu as bien compris, notamment quand il y a redite 10 mn plus tard le post d'en dessous ;-) mais tu t'épuiseras avant lui.
Bien souvent remettre les gens à leur place poliment fonctionne et leur fait se rendre compte de l'inanité d'un acharnement à ne rien laisser passer.
bin remonte en amont du processus : plutôt qu'une micro-demande ponctuelle non justifiée, tu peux l'inclure dans un projet plus large, dont l'une des demandes légitimes est de disposer d'un miroir ; à ce moment, tu auras des ressources pour identifier ce qu'il est possible de faire pour la synchro et tu donneras la visibilité à tes interlocuteurs sur le cadrage que tu as effectué, de bout en bout.
c'est surtout des fonctions que tu trouves dans Nautilus en fait...
effectivement le renommage, l'heure, éventuellement une autre vue ça pourrait être utile.
L'idéal serait de ne pas avoir à se préoccuper de donner des noms à des fichiers dans certains cas ;-) et d'être capable de les retrouver ensuite.
dans Nautilus :
ctrl-S : sélectionner avec un motif (une regex comme *.txt va sélectionner tous les fichiers du répertoire courant) => tu as le même avec thunar
ctrl-L : cela va dans la barre pour changer d'emplacement, tu peux taper directement /usr/sbin/ ou tout ce que tu veux...
De quoi tu parles ? :-)
comme indiqué au haut de mon post Pour parler d'un sujet que je connais, Mandriva et par rapport à mon titre de ceux qui "suivent" et non qui avancent à la même cadence que l'upstream : cela concerne les distribs' stables (donc peut concerner Fedora 7, Fedora 8, maintenant Fedora 9 mais pas rawhide).
Fedora 8 en est au 2.6.23.1 d'après distrowatch. Dans cette branche Andrew Morton en est au 2.6.23.17, non pris en compte tel quel (si j'en crois distrowatch). Fedora 9, 2.6.25 contre 2.6.25.4 et rawhide d'ailleurs 2.6.25.2.
Sur Mandriva Linux 2008.1, il y a le 2.6.24.4, Andrew en est au 2.6.24.7 et je ne crois pas qu'il sera pris en compte, cela passera par des backports au mieux ou sinon il y a le kernel-linus-2.6.25-0.rc6.1mdv (principalement upstream).
packages.ubuntu.com est down, je n'ai pas vérifié mais je ne pense pas qu'ils soient à la dernière version non plus.
Je ne remets pas en cause, je constate simplement des difficultés rencontrées par les distributions à accrocher au processus : cela sert pour le choix initial du kernel, ensuite chaque distrib' a sa politique de mise à jour et de constitution de "son" kernel (backports, dkms). Mandriva va aussi chercher des pilotes qui n'ont pas encore fait l'effort d'être inclus dans le kernel (il y a aussi de l'upstream du kernel hein ;-) ).
Pour les weak-updates, je n'ai pas trop compris c'est dans le paquet kernel de Fedora ?
Pour les dkms, je notais simplement un moyen supplémentaire de mettre à jour par morceau le kernel plutôt que d'attendre qu'un nouveau kernel soit packagé. Ayant bossé sur l'upstream de module, c'est intéressant quand ton code n'a pas encore été poussé dans le kernel et qu'une distrib' s'y intéresse (le paquet dkms permet de constituer le backport directement pour une floppée de versions de kernels, même si ce n'était pas l'utilisation initiale prévue pour dkms).
Oui, je parle du build service.
Pour moi cela pourrait permettre aux mainteneurs de distribs' et à l'upstream de dialoguer plus facilement :
- fourniture plus facile de toutes les traces de compil'
- possible implication de l'upstream dans plus de distributions (évite le "coût" initial d'installation de multiples distribution), permet de voir ce que ça donne sur une autre distrib' que la sienne et permet même de travailler ;-) même si cela se restreint à la compil' / packaging c'est pas mal
bon il ne faudrait pas que ça se transforme en ferme à backports personnels, mais si ça peut contribuer à travailler à plus nombreux sur le packaging de certains paquets, c'est pas mal. C'est surtout sur le volet applications que cela peut être pratique (pas trop de dépendances) àmha. Pour des mises à jour de gcc mieux vaut avoir une synchro un peu plus importante.
Pour dkms, je notais le point de deux points de vue :
- en terme de découpage du kernel : ajout de pilotes non encore inclus au kernel (c'est l'utilisation "standard"), ajout de versions de pilotes inclus dans kernel suivant
- en terme de packaging, un gros paquet kernel d'un côté, des petits paquets à côté, avec la contrainte que le gcc ne bouge pas entre les deux
dans certains cas (l'exemple donné), cela permet de découpler et de ne pas se trimballer une "grosse" version de kernel
Bin je vais te donner 2 lectures de ce que tu as écrit :
Pour le 1), 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 ?)
Cela peut se comprendre ainsi, en forçant le trait :
a) des tentatives ont foiré, par exemple celle de Mandriva et TurboLinux
b) il y a eu déjà des tentatives, par exemple celle de Mandriva (d'ailleurs où cela en est-il, cela porte-il ses fruits ?)
Si tu as voulu dire le b), bin tu t'es mal exprimé, tu peux l'assumer hein.
Ton chahutage de boklm est ce qui me fait dire que tu sautes bien vite aux conclusions, la réponse que tu me fais le démontre bien, tu vas même au plafond ;-) (un peu comme le double-jump aux dérivés libres de ioquake3)
Tu n'as pas d'élément, mais 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é, mais tu fais très bien les questions et les réponses donc ça va ;-) ).
Je ne te rendrai pas de comptes, mais je me renseignerai, ne t'inquiète pas, pour mon info (et je ne te dirai peut-être rien, na :p ou pas).
Pour moi ce sujet de synchronisation est important mais pas pour le proprio (enfin ce n'est pas l'aspect qui m'intéresse le plus, à eux d'essayer de suivre, pas au libre de s'adapter) ; la synchro est intéressante pour éviter de rater les échéances et courir derrière le noyau (notamment le noyau, mais il y a aussi côté applications).
Je préfère franchement l'approche de Fedora sur le sujet, prendre les travaux upstream du moment et les intégrer / traiter pour faire avancer.
Pour parler d'un sujet que je connais, Mandriva a choisi une approche intermédiaire sur le noyau, avec le paquet kernel-linus notamment, mais il est dépouillé des pilotes complémentaires et surtout présent àmha à des fins de tests (donc plutôt orienté cooker, même s'il peut servir sur une version stable).
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.
Un cas précis que j'ai en tête est le pilote wifi ipw3945, iwl3945, iwlwifi :
- en fait j'ai du matériel très bien supporté par ipw3945[1]
- 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]
- Mandriva a en fait proposé les 3 pilotes, sous forme de dkms (avec la pile wifi qui fonctionne avec chaque version)
- cela fonctionne pas mal et permet de choisir celui qui fonctionne le mieux pour son matériel, mais ce n'est plus une distribution "monolithique" du noyau : cela en devient modulaire au niveau du packaging aussi
Je ne sais pas si d'autres distributions ont adopté le même genre "d'astuce" pour l'utilisation de dkms ou le découpage des modules (bon là c'est pour l'instant une "exception"). Mais concrètement, cela permet d'utiliser dkms pour des pilotes libres et les recompiler "à la volée" ce qui me semble intéressant, évite de rebooter dans pas mal de cas vu qu'un modprobe -r est souvent suffisant (dkms à la base était plutôt vu pour nvidia ou ati par exemple, mais il peut tout à fait être utilisé pour du libre). Tout l'intérêt de dkms est de "gentoo-ifier" les modules : une recompil' et zou il remplace celui dans le kernel, c'est intéressant pour certains modules bien découplés du reste du kernel (l'exemple du wifi étant un peu biaisé vu qu'il y a des dépendances à d'autres modules tout de même mais ça le rend d'autant plus intéressant).
Bon je voulais parler de Gnome et KDE, mais pas forcément besoin : de ce que j'en vois, les versions de dév' -svn et rc sont assez bien suivies pour bénéficier dans la distrib' à sa sortie d'une version stable rapidement (dans les 2-3 jours de la release pour Gnome, voire le jour même pour KDE, Mandriva ayant les ressources sur le sujet). Pour KDE4, le choix pour la 2008.1 Spring a été de préserver les utilisateurs la version 4.0 étant plutôt pour les aventureux et les développeurs : l'install' dans /opt permet d'avoir les 2 en parallèle. Cela change pour la 2009.0 iirc.
Il y aurait les applications à traiter : je pense que c'est du côté des fermes de compilation que cela peut s'améliorer. OpenSuse a une ferme multi-distribution à ce que m'en disait un contributeur à Solutions Linux, cela pourrait être intéressant pour Mandriva et Fedora de regarder si ça marche vraiment (ça peut toujours faire un complément aux fermes disponibles en libre pour Fedora ou Mandriva). Cela permettrait d'avoir des dépôts "testing" mis à jour avec des versions -svn des applications par exemple (utilisable tant par cooker que 2008.1). Il me semble qu'Ubuntu propose de se construire ses propres paquets avec les PPA aka "personal packages archive" que Étienne Bersac avait présenté[3] succintement.
Cela pourrait être un moyen de répondre à la demande des utilisateurs et des développeurs upstream d'avoir des packages à jour (ou en tout cas de voir rapidement si le packaging "automatique" fonctionne encore ou doit être actualisé).
Ces fermes permettraient d'envisager aussi une recompilation massive, que ce soit pour un changement de gcc ou une option de compilation systématique. Cela a par exemple été fait pour Debian, cf.[4] mais il vaut mieux avoir du temps pour éplucher les logs d'erreur (il n'y a pas que la compilation qui prenne du temps).
Bref, voici quelques éléments qui peuvent servir à avancer àmha, sans prétendre être complet.
Tu as en synthèse ce qui en est sorti sur http://blog.mandriva.com/2008/04/08/bits-and-pieces-about-th(...) La 2008.1 Spring inclut les travaux qui en sont sortis (sur gcc, kernel, rpm...), beaucoup de paquets ont maintenant une extension mnb1 et non plus mdv, comme ont pu le remarquer beaucoup d'utilisateurs de Mandriva Linux.
Donc oui, ça avance, il n'y a pas de communication particulière à faire pour l'instant à ce que j'en vois sur le net.
De toute façon, c'est surtout un travail de coordination, plus facile à faire entre 2 entités que dans un magma où Mandriva n'aurait pas forcément son mot à dire. L'important est qu'il y ait des choses de faites, les échos que j'en ai eu à Solutions Linux sont plutôt bons, les résultats se sont vus dans la Spring.
En aparté, tu sais, Mandriva est une société, elle communique comme elle veut et ne te doit pas de comptes ou d'explications, quand bien même elle bosse dans le libre : son meilleur livrable reste les logiciels libres produits et la distrib' qui profite à tous. Moi aussi à une époque j'aurais voulu plus de communication, puis en tant que simple utilisateur je suis devenu rationnel : cela ne me regarde pas forcément et ce n'est pas à moi d'exiger cela ;-)
Il y en aura plus de dit le moment utile àmha, par exemple quand TurboLinux sortira sa propre version.
ah tiens encore un qui réécrit l'histoire, donc bon pour être clair encore une fois :
- le problème est lié initialement à LG qui a reconnu le non respect des normes (utilisation d'une commande de flush pour "réinitialiser" leur firmware : d'où perte du firmware rendant inutilisable le lecteur). LG a par la suite fourni une manipulation et un firmware permettant de récupérer les lecteur et flasher un firmware corrigé
- la commande en cause était envoyé lors du boot du kernel 2.4.22, conformément aux normes cela permettait d'initialiser le lecteur pour ceux respectant la norme (mais virait le firmware pour les lecteurs LG)
- le kernel 2.4.22 était fourni avec Mandrake 9.2, Suse 9.2 (iirc) et d'autres distributions ont été aussi touchées (voir leurs bugtracking respectifs, il y avait quelques développeurs qui y avaient laissé leur lecteur et racheté un pour 20 € pensant qu'il était trop ancien et avait lâché), simplement c'est Mandrake dont le planning de sortie était en premier qui a mis le problème en évidence, de plus en plus de monde étant touchés dans les forums et il a bien fallu se rendre compte qu'il y avait un bug quelque part (mais en fait pas dans le kernel hein, ni dans Mandrake)
- donc bon le matériel défectueux ça arrive, le non respect des normes ce n'est pas la bonne manière de faire, certains l'ont appris à leurs dépends (et aux dépends de leurs clients, ce qui est déjà plus dommageable)
- sur cet épisode, LG a reconnu ses torts et Mandrakesoft avait publié un avertissement dans les errata et notes de version, ce qui est la bonne manière de réagir en communiquant sur le souci et indiquant une résolution
vala, j'espère que c'est bien clair ? quelques infos complémentaires sur http://www.pcinpact.com/actu/news/Lecteurs_LG_Mandrake_92_Re(...) et http://www.zdnet.fr/actualites/informatique/0,39040745,39128(...)
1. je clique sur les liens donnés et je regarde le chiffre en bas à droite et sinon http://www.dwheeler.com/sloccount/sloccount.html te donnera d'autres éléments
2. bin je forke Gimp et zou je te le fais en une fois :-) il y a d'autres méthodes
Cela n'empêche pas ces projets ayant coûté plus d'un million d'euro (ton critère) de continuer à se développer... visiblement ils ont trouvé leur modèle économique viable non ?
euh non, je pars du principe qu'il y a des processus d'entreprise et que les admins sont responsables.
Dès lors que la demande leur parvient en direct, c'est qu'elle n'a pas forcément été complètement étudiée en amont (faut peut-être essayer de se mettre à leur place aussi).
Mieux vaut suivre les processus et arriver avec tous les tampons qu'il faut, c'est toujours plus simple pour être légitime et avoir accès aux proxy dédiés applications par exemple qui eux ne sont pas forcément soumis aux mêmes vérifications.
Tu montres patte blanche, ça passe ; t'arrives avec ton besoin non avéré, tu te fais mettre dans la pile non urgente.
ça oblige à remonter d'un niveau, cela peut paraître plus compliqué, mais c'est tout bénéf' au final.
As-tu demandé à tes gentils admins du pare-feu s'ils accepteraient d'autres protocoles que http pour constituer ton miroir ?
- notamment ftp ou plutôt rsync, rsync présentant l'avantage de n'aller chercher que ce qui est nécessaire et permettant des reprises
- cela permettra d'identifier ton serveur concerné (point d'origine du flux) et le serveur distant (point de destination)
- as-tu identifié la volumétrie estimée, ce qui leur permettra de dimensionner la bande passante afférente ? leur as-tu proposé pour l'initialisation (qui demandera minimum 20 Go) de plutôt le faire par le LAN via un disque usb (par exemple) alimenté par tes soins
- à quels horaires comptes-tu faire tes mises à jour ? est-ce bien dans un créneau moins chargé au niveau réseau ?
S'il y a une de ces questions que tu n'as jamais traité avec eux, pas trop étonnant que tu te sois fait gentiment éconduire. Déjà le titre de ton post "bypass du proxy" montre que tu adoptes le _mauvais_ état d'esprit, quand bien même tu tentes de te rattrapper aux branches par la suite.
En traitant ces différents points tu pourras montrer que tu maîtrises leurs différentes problématiques, que tu es prêt à faire quelques concessions, que la demande ne va pas partir dans tous les sens (oui oui, pour toi ça paraît évident, ça va sans dire, ça va mieux en le disant). Au passage tu pourras leur signaler ce pépin avec l'antivirus, qui te pénalise, alors que les paquets sont signés sur les différents miroirs des distributions et pourraient _à ce titre_ ne pas être obligé de passer par le scan anti-virus et ainsi décharger un peu votre proxy.
Essaie aussi de fournir les courbes de consommation réseau que tu as engendrées, cela montrera que tu as pris en compte une partie du problème. En contrepartie tu indiqueras que cela permet d'avoir un flux _identifié_ avec l'extérieur plutôt que d'avoir autant de serveurs/postes clients qui se connectent anarchiquement vers l'extérieur et démultipliant (rapidement) les volumétries ; alors que ce que tu proposes avec un miroir interne rationnalise le tout et permet de n'avoir principalement que des "coûts" LAN.
Eventuellement, demande si un lien dédié est envisageable (mais je n'y crois que très peu) et soit prêt à en assumer les coûts de mise en place.
Bon courage dans tes démarches.
[^] # Re: Sémaphore et mutex
Posté par BAud (site web personnel) . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 7.
[^] # Re: Un nouveau pas !
Posté par BAud (site web personnel) . En réponse à la dépêche Lemon : Gérez votre caisse en toute liberté !. Évalué à 3.
Bien souvent remettre les gens à leur place poliment fonctionne et leur fait se rendre compte de l'inanité d'un acharnement à ne rien laisser passer.
[^] # Re: Licence
Posté par BAud (site web personnel) . En réponse au journal Le random chat, enfin possible par Jabber. Évalué à 3.
[^] # Re: ftp, rsync...
Posté par BAud (site web personnel) . En réponse au message Bypass du proxy. Évalué à 2.
# la tournée des enfoirés
Posté par BAud (site web personnel) . En réponse au journal [vidéo] L'accord Novell Microsoft vu par Eben Moglen. Évalué à 2.
sinon, la cité de la peur, rha flûte pris aussi
ou tout simplement la valse des intimidations
# spam journal
Posté par BAud (site web personnel) . En réponse au journal Rions un peu avec les spams traduits. Évalué à 8.
d'ailleurs je vous livre une perle qu'il contient :
Mais ici il y eu une innovation
[^] # Re: Si au moins ils allaient jusqu'au bout...
Posté par BAud (site web personnel) . En réponse au journal FSF et distributions. Évalué à 4.
http://www.debian.org/logos/index.fr.html
quitte à copier/coller autant donner la référence :-)
[^] # Re: patrick_g, sors de ce corps !
Posté par BAud (site web personnel) . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 7.
[^] # Re: sélecteur de fichiers
Posté par BAud (site web personnel) . En réponse au journal QGtkStyle: un style Qt qui utilise les widgets GTK+. Évalué à 2.
effectivement le renommage, l'heure, éventuellement une autre vue ça pourrait être utile.
L'idéal serait de ne pas avoir à se préoccuper de donner des noms à des fichiers dans certains cas ;-) et d'être capable de les retrouver ensuite.
[^] # Re: sélecteur de fichiers
Posté par BAud (site web personnel) . En réponse au journal QGtkStyle: un style Qt qui utilise les widgets GTK+. Évalué à 2.
ctrl-S : sélectionner avec un motif (une regex comme *.txt va sélectionner tous les fichiers du répertoire courant) => tu as le même avec thunar
ctrl-L : cela va dans la barre pour changer d'emplacement, tu peux taper directement /usr/sbin/ ou tout ce que tu veux...
Il est très bien le sélecteur de fichier (en mode étendu) http://www.gnome.org/projects/gnumeric/doc/sect-file-save-di(...)
tu lui reproches quoi concrètement ?
[^] # Re: synchro ou suivre ou avancer
Posté par BAud (site web personnel) . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
comme indiqué au haut de mon post Pour parler d'un sujet que je connais, Mandriva et par rapport à mon titre de ceux qui "suivent" et non qui avancent à la même cadence que l'upstream : cela concerne les distribs' stables (donc peut concerner Fedora 7, Fedora 8, maintenant Fedora 9 mais pas rawhide).
Fedora 8 en est au 2.6.23.1 d'après distrowatch. Dans cette branche Andrew Morton en est au 2.6.23.17, non pris en compte tel quel (si j'en crois distrowatch). Fedora 9, 2.6.25 contre 2.6.25.4 et rawhide d'ailleurs 2.6.25.2.
Sur Mandriva Linux 2008.1, il y a le 2.6.24.4, Andrew en est au 2.6.24.7 et je ne crois pas qu'il sera pris en compte, cela passera par des backports au mieux ou sinon il y a le kernel-linus-2.6.25-0.rc6.1mdv (principalement upstream).
packages.ubuntu.com est down, je n'ai pas vérifié mais je ne pense pas qu'ils soient à la dernière version non plus.
Je ne remets pas en cause, je constate simplement des difficultés rencontrées par les distributions à accrocher au processus : cela sert pour le choix initial du kernel, ensuite chaque distrib' a sa politique de mise à jour et de constitution de "son" kernel (backports, dkms). Mandriva va aussi chercher des pilotes qui n'ont pas encore fait l'effort d'être inclus dans le kernel (il y a aussi de l'upstream du kernel hein ;-) ).
Pour les weak-updates, je n'ai pas trop compris c'est dans le paquet kernel de Fedora ?
Pour les dkms, je notais simplement un moyen supplémentaire de mettre à jour par morceau le kernel plutôt que d'attendre qu'un nouveau kernel soit packagé. Ayant bossé sur l'upstream de module, c'est intéressant quand ton code n'a pas encore été poussé dans le kernel et qu'une distrib' s'y intéresse (le paquet dkms permet de constituer le backport directement pour une floppée de versions de kernels, même si ce n'était pas l'utilisation initiale prévue pour dkms).
[^] # Re: synchro ou suivre ou avancer
Posté par BAud (site web personnel) . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
Pour moi cela pourrait permettre aux mainteneurs de distribs' et à l'upstream de dialoguer plus facilement :
- fourniture plus facile de toutes les traces de compil'
- possible implication de l'upstream dans plus de distributions (évite le "coût" initial d'installation de multiples distribution), permet de voir ce que ça donne sur une autre distrib' que la sienne et permet même de travailler ;-) même si cela se restreint à la compil' / packaging c'est pas mal
bon il ne faudrait pas que ça se transforme en ferme à backports personnels, mais si ça peut contribuer à travailler à plus nombreux sur le packaging de certains paquets, c'est pas mal. C'est surtout sur le volet applications que cela peut être pratique (pas trop de dépendances) àmha. Pour des mises à jour de gcc mieux vaut avoir une synchro un peu plus importante.
Pour dkms, je notais le point de deux points de vue :
- en terme de découpage du kernel : ajout de pilotes non encore inclus au kernel (c'est l'utilisation "standard"), ajout de versions de pilotes inclus dans kernel suivant
- en terme de packaging, un gros paquet kernel d'un côté, des petits paquets à côté, avec la contrainte que le gcc ne bouge pas entre les deux
dans certains cas (l'exemple donné), cela permet de découpler et de ne pas se trimballer une "grosse" version de kernel
[^] # Re: La réponse d'Aaron Seigo
Posté par BAud (site web personnel) . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 4.
Pour le 1), 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 ?)
Cela peut se comprendre ainsi, en forçant le trait :
a) des tentatives ont foiré, par exemple celle de Mandriva et TurboLinux
b) il y a eu déjà des tentatives, par exemple celle de Mandriva (d'ailleurs où cela en est-il, cela porte-il ses fruits ?)
Si tu as voulu dire le b), bin tu t'es mal exprimé, tu peux l'assumer hein.
Ton chahutage de boklm est ce qui me fait dire que tu sautes bien vite aux conclusions, la réponse que tu me fais le démontre bien, tu vas même au plafond ;-) (un peu comme le double-jump aux dérivés libres de ioquake3)
Tu n'as pas d'élément, mais 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é, mais tu fais très bien les questions et les réponses donc ça va ;-) ).
Je ne te rendrai pas de comptes, mais je me renseignerai, ne t'inquiète pas, pour mon info (et je ne te dirai peut-être rien, na :p ou pas).
et je vais ouvrir un autre thread tout en bas pour les sujets constructifs :D https://linuxfr.org/comments/932269.html#932269
# synchro ou suivre ou avancer
Posté par BAud (site web personnel) . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 2.
Je préfère franchement l'approche de Fedora sur le sujet, prendre les travaux upstream du moment et les intégrer / traiter pour faire avancer.
Pour parler d'un sujet que je connais, Mandriva a choisi une approche intermédiaire sur le noyau, avec le paquet kernel-linus notamment, mais il est dépouillé des pilotes complémentaires et surtout présent àmha à des fins de tests (donc plutôt orienté cooker, même s'il peut servir sur une version stable).
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.
Un cas précis que j'ai en tête est le pilote wifi ipw3945, iwl3945, iwlwifi :
- en fait j'ai du matériel très bien supporté par ipw3945[1]
- 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]
- Mandriva a en fait proposé les 3 pilotes, sous forme de dkms (avec la pile wifi qui fonctionne avec chaque version)
- cela fonctionne pas mal et permet de choisir celui qui fonctionne le mieux pour son matériel, mais ce n'est plus une distribution "monolithique" du noyau : cela en devient modulaire au niveau du packaging aussi
Je ne sais pas si d'autres distributions ont adopté le même genre "d'astuce" pour l'utilisation de dkms ou le découpage des modules (bon là c'est pour l'instant une "exception"). Mais concrètement, cela permet d'utiliser dkms pour des pilotes libres et les recompiler "à la volée" ce qui me semble intéressant, évite de rebooter dans pas mal de cas vu qu'un modprobe -r est souvent suffisant (dkms à la base était plutôt vu pour nvidia ou ati par exemple, mais il peut tout à fait être utilisé pour du libre). Tout l'intérêt de dkms est de "gentoo-ifier" les modules : une recompil' et zou il remplace celui dans le kernel, c'est intéressant pour certains modules bien découplés du reste du kernel (l'exemple du wifi étant un peu biaisé vu qu'il y a des dépendances à d'autres modules tout de même mais ça le rend d'autant plus intéressant).
Bon je voulais parler de Gnome et KDE, mais pas forcément besoin : de ce que j'en vois, les versions de dév' -svn et rc sont assez bien suivies pour bénéficier dans la distrib' à sa sortie d'une version stable rapidement (dans les 2-3 jours de la release pour Gnome, voire le jour même pour KDE, Mandriva ayant les ressources sur le sujet). Pour KDE4, le choix pour la 2008.1 Spring a été de préserver les utilisateurs la version 4.0 étant plutôt pour les aventureux et les développeurs : l'install' dans /opt permet d'avoir les 2 en parallèle. Cela change pour la 2009.0 iirc.
Il y aurait les applications à traiter : je pense que c'est du côté des fermes de compilation que cela peut s'améliorer. OpenSuse a une ferme multi-distribution à ce que m'en disait un contributeur à Solutions Linux, cela pourrait être intéressant pour Mandriva et Fedora de regarder si ça marche vraiment (ça peut toujours faire un complément aux fermes disponibles en libre pour Fedora ou Mandriva). Cela permettrait d'avoir des dépôts "testing" mis à jour avec des versions -svn des applications par exemple (utilisable tant par cooker que 2008.1). Il me semble qu'Ubuntu propose de se construire ses propres paquets avec les PPA aka "personal packages archive" que Étienne Bersac avait présenté[3] succintement.
Cela pourrait être un moyen de répondre à la demande des utilisateurs et des développeurs upstream d'avoir des packages à jour (ou en tout cas de voir rapidement si le packaging "automatique" fonctionne encore ou doit être actualisé).
Ces fermes permettraient d'envisager aussi une recompilation massive, que ce soit pour un changement de gcc ou une option de compilation systématique. Cela a par exemple été fait pour Debian, cf.[4] mais il vaut mieux avoir du temps pour éplucher les logs d'erreur (il n'y a pas que la compilation qui prenne du temps).
Bref, voici quelques éléments qui peuvent servir à avancer àmha, sans prétendre être complet.
[1] http://sophie.zarb.org/rpm/2008.1,x86_64/dkms-ipw3945 ancien pilote
[2] http://sophie.zarb.org/rpm/2008.1,x86_64/dkms-iwlwifi pilote plus récent + pile wifi
[3] https://linuxfr.org/~bersace/25359.html utilisation de ppa
[4] http://julien.danjou.info/blog/index.php/post/2007/08/16/Deb(...)
[^] # Re: La réponse d'Aaron Seigo
Posté par BAud (site web personnel) . En réponse au journal Mark Shuttleworth : il remet (encore) ça. Évalué à 3.
Les travaux ont été annoncés en Janvier 2008 avec le manbo-labs,
blino en avait parlé sur http://blino.org/blog/mandriva/manbo-labs-creation.html
ici un journal en avait parlé https://linuxfr.org/~JRM/25998.html
Tu as en synthèse ce qui en est sorti sur http://blog.mandriva.com/2008/04/08/bits-and-pieces-about-th(...) La 2008.1 Spring inclut les travaux qui en sont sortis (sur gcc, kernel, rpm...), beaucoup de paquets ont maintenant une extension mnb1 et non plus mdv, comme ont pu le remarquer beaucoup d'utilisateurs de Mandriva Linux.
Cela va continuer sur le kernel pour la 2009.0 comme embrayé sur http://wiki.mandriva.com/en/Manbo_Core2_kernel
Donc oui, ça avance, il n'y a pas de communication particulière à faire pour l'instant à ce que j'en vois sur le net.
De toute façon, c'est surtout un travail de coordination, plus facile à faire entre 2 entités que dans un magma où Mandriva n'aurait pas forcément son mot à dire. L'important est qu'il y ait des choses de faites, les échos que j'en ai eu à Solutions Linux sont plutôt bons, les résultats se sont vus dans la Spring.
En aparté, tu sais, Mandriva est une société, elle communique comme elle veut et ne te doit pas de comptes ou d'explications, quand bien même elle bosse dans le libre : son meilleur livrable reste les logiciels libres produits et la distrib' qui profite à tous. Moi aussi à une époque j'aurais voulu plus de communication, puis en tant que simple utilisateur je suis devenu rationnel : cela ne me regarde pas forcément et ce n'est pas à moi d'exiger cela ;-)
Il y en aura plus de dit le moment utile àmha, par exemple quand TurboLinux sortira sa propre version.
[^] # Re: samba = serveur de fichier
Posté par BAud (site web personnel) . En réponse au message Serveur mp3 et films. Évalué à 3.
Sur mon LAN, je fais un simple
sshfs -o allow_other -o gid=500 -o uid=500 baud@192.168.1.100:/mnt/data/Music/mp3 /media/Music
[^] # Re: la rache
Posté par BAud (site web personnel) . En réponse au message conception de NAGIOS. Évalué à 2.
[^] # Re: Limite du développement bénévole
Posté par BAud (site web personnel) . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 9.
- le problème est lié initialement à LG qui a reconnu le non respect des normes (utilisation d'une commande de flush pour "réinitialiser" leur firmware : d'où perte du firmware rendant inutilisable le lecteur). LG a par la suite fourni une manipulation et un firmware permettant de récupérer les lecteur et flasher un firmware corrigé
- la commande en cause était envoyé lors du boot du kernel 2.4.22, conformément aux normes cela permettait d'initialiser le lecteur pour ceux respectant la norme (mais virait le firmware pour les lecteurs LG)
- le kernel 2.4.22 était fourni avec Mandrake 9.2, Suse 9.2 (iirc) et d'autres distributions ont été aussi touchées (voir leurs bugtracking respectifs, il y avait quelques développeurs qui y avaient laissé leur lecteur et racheté un pour 20 € pensant qu'il était trop ancien et avait lâché), simplement c'est Mandrake dont le planning de sortie était en premier qui a mis le problème en évidence, de plus en plus de monde étant touchés dans les forums et il a bien fallu se rendre compte qu'il y avait un bug quelque part (mais en fait pas dans le kernel hein, ni dans Mandrake)
- donc bon le matériel défectueux ça arrive, le non respect des normes ce n'est pas la bonne manière de faire, certains l'ont appris à leurs dépends (et aux dépends de leurs clients, ce qui est déjà plus dommageable)
- sur cet épisode, LG a reconnu ses torts et Mandrakesoft avait publié un avertissement dans les errata et notes de version, ce qui est la bonne manière de réagir en communiquant sur le souci et indiquant une résolution
vala, j'espère que c'est bien clair ? quelques infos complémentaires sur http://www.pcinpact.com/actu/news/Lecteurs_LG_Mandrake_92_Re(...) et http://www.zdnet.fr/actualites/informatique/0,39040745,39128(...)
[^] # Re: L'éthique à l'heure du numérique
Posté par BAud (site web personnel) . En réponse au journal Sur la philosophie de M. Stallman. Évalué à 2.
2. bin je forke Gimp et zou je te le fais en une fois :-) il y a d'autres méthodes
[^] # Re: L'éthique à l'heure du numérique
Posté par BAud (site web personnel) . En réponse au journal Sur la philosophie de M. Stallman. Évalué à 5.
http://www.ohloh.net/projects/blender $ 31,517,700 (c'est plus de 1 M€)
http://www.ohloh.net/projects/gimp $ 19,580,863
http://www.ohloh.net/projects/inkscape $ 12,370,013
http://www.ohloh.net/projects/kde $ 67,158,715
http://www.ohloh.net/projects/gnome $ 285,322,119
http://www.ohloh.net/projects/7196 open arena $ 2,485,360
http://www.ohloh.net/projects/6795 tremulous $ 2,443,007
http://www.ohloh.net/projects/wesnoth $ 1,839,610
http://www.ohloh.net/projects/8109 tesseract-ocr $ 1,276,523
http://www.ohloh.net/projects/5461 ocropus $ 929,779
http://www.ohloh.net/projects/4314 Tiny ERP $ 2,350,075
http://www.ohloh.net/projects/erp5 $ 97,223,841
http://www.ohloh.net/projects/mysql
http://www.ohloh.net/projects/phpmyadmin $ 2,345,765
http://www.ohloh.net/projects/postgresql $ 8,076,467
Cela n'empêche pas ces projets ayant coûté plus d'un million d'euro (ton critère) de continuer à se développer... visiblement ils ont trouvé leur modèle économique viable non ?
# la rache
Posté par BAud (site web personnel) . En réponse au message conception de NAGIOS. Évalué à 3.
et un zest de http://poudreverte.org les a beaucoup aidé aussi àmha
[^] # Re: Agréable
Posté par BAud (site web personnel) . En réponse au journal Tri pas logique. Évalué à 1.
<pub>N'hésitez pas à en soumettre sur https://linuxfr.org/redacteurs/ </pub>
et sinon pour ceux à Paris à la fin du mois, vous pouvez passer rue d'Aboukir dans les locaux de Mandriva https://linuxfr.org/2008/05/16/24094.html
[^] # Re: ftp, rsync...
Posté par BAud (site web personnel) . En réponse au message Bypass du proxy. Évalué à 2.
Dès lors que la demande leur parvient en direct, c'est qu'elle n'a pas forcément été complètement étudiée en amont (faut peut-être essayer de se mettre à leur place aussi).
Mieux vaut suivre les processus et arriver avec tous les tampons qu'il faut, c'est toujours plus simple pour être légitime et avoir accès aux proxy dédiés applications par exemple qui eux ne sont pas forcément soumis aux mêmes vérifications.
Tu montres patte blanche, ça passe ; t'arrives avec ton besoin non avéré, tu te fais mettre dans la pile non urgente.
ça oblige à remonter d'un niveau, cela peut paraître plus compliqué, mais c'est tout bénéf' au final.
# ftp, rsync...
Posté par BAud (site web personnel) . En réponse au message Bypass du proxy. Évalué à 2.
- notamment ftp ou plutôt rsync, rsync présentant l'avantage de n'aller chercher que ce qui est nécessaire et permettant des reprises
- cela permettra d'identifier ton serveur concerné (point d'origine du flux) et le serveur distant (point de destination)
- as-tu identifié la volumétrie estimée, ce qui leur permettra de dimensionner la bande passante afférente ? leur as-tu proposé pour l'initialisation (qui demandera minimum 20 Go) de plutôt le faire par le LAN via un disque usb (par exemple) alimenté par tes soins
- à quels horaires comptes-tu faire tes mises à jour ? est-ce bien dans un créneau moins chargé au niveau réseau ?
S'il y a une de ces questions que tu n'as jamais traité avec eux, pas trop étonnant que tu te sois fait gentiment éconduire. Déjà le titre de ton post "bypass du proxy" montre que tu adoptes le _mauvais_ état d'esprit, quand bien même tu tentes de te rattrapper aux branches par la suite.
En traitant ces différents points tu pourras montrer que tu maîtrises leurs différentes problématiques, que tu es prêt à faire quelques concessions, que la demande ne va pas partir dans tous les sens (oui oui, pour toi ça paraît évident, ça va sans dire, ça va mieux en le disant). Au passage tu pourras leur signaler ce pépin avec l'antivirus, qui te pénalise, alors que les paquets sont signés sur les différents miroirs des distributions et pourraient _à ce titre_ ne pas être obligé de passer par le scan anti-virus et ainsi décharger un peu votre proxy.
Essaie aussi de fournir les courbes de consommation réseau que tu as engendrées, cela montrera que tu as pris en compte une partie du problème. En contrepartie tu indiqueras que cela permet d'avoir un flux _identifié_ avec l'extérieur plutôt que d'avoir autant de serveurs/postes clients qui se connectent anarchiquement vers l'extérieur et démultipliant (rapidement) les volumétries ; alors que ce que tu proposes avec un miroir interne rationnalise le tout et permet de n'avoir principalement que des "coûts" LAN.
Eventuellement, demande si un lien dédié est envisageable (mais je n'y crois que très peu) et soit prêt à en assumer les coûts de mise en place.
Bon courage dans tes démarches.
# AdL
Posté par BAud (site web personnel) . En réponse à la dépêche 10 ans de Mandriva, Install party Mandriva Linux 2008.1 Spring. Évalué à 1.
Pour DDR, les plus avertis auront bien sûr identifié Dance_Dance_Revolution (mais mieux vaut s'entraîner avant...).