Au sein de Debian, Zack s'occupe des paquets liés au langage de programmation OCaml et il est aussi très impliqué dans tout ce qui touche l'assurance qualité. En septembre 2009, il a également lancé l'initiative "Release Critical Bugs of the Week" qui se propose de corriger chaque semaine des bugs bloquants du projet Debian.
En lisant ce qui précède, on comprend que Zack est quelqu'un de très occupé. Pour ajouter à son fardeau, j'ai essayé de collecter les questions se trouvant dans la proposition d'entretien initiée par Florent, j'en ai ajouté quelques-unes et j'ai envoyé le tout par mail. Il a eu la gentillesse d'accepter de répondre à cet entretien pour les lecteurs de LinuxFr. Qu'il en soit chaudement remercié. LinuxFr : Est-ce qu'il y a des retours venant d'Ubuntu? Les correctifs de bugs dans les paquets Ubuntu sont-ils renvoyés à Debian ou pas?
Stefano Zacchiroli : Il y a des contributions qui reviennent vers nous, oui. Certaines d'entre elles peuvent être suivies avec le système de suivi des bugs de Debian (BTS). Par exemple à la fin de cette page wiki il y a plusieurs liens intéressants. Ils listent tous les rapports de bugs Debian venant d'Ubuntu ainsi que tous les rapports de bugs qui contiennent un patch venant d'Ubuntu. Un autre exemple de collaboration, ce sont les teams de packaging "mixtes" qui sont formés de gens de Debian et d'Ubuntu.
Est-ce que ça veut dire que la collaboration est parfaite ? Évidemment, non. En principe Debian devrait attendre d'Ubuntu qu'elle remonte tout son travail vers elle, respectant ainsi parfaitement une saine relation entre "upstream" et downstream". Mais en principe, nous aussi chez Debian, nous devrions être parfaits dans la remontée de nos changements vers nos upstreams...et nous ne le sommes pas.
Disons que nous commençons à réaliser tout cela et que nous travaillons ensemble pour diminuer la "viscosité" du flot de patchs dans toutes les directions.
LinuxFr : Quelles sont, selon toi, les raisons de préférer Debian par rapport à Ubuntu ?
Stefano Zacchiroli : J'ai discuté du sujet plus général de la pertinence de Debian dans la récente présentation "bits from the DPL" que j'ai donnée lors de la conférence DebConf à New York au début du mois d'août. La vidéo est disponible ici.
Debian reste unique parmi les distributions "mainstream" pour plusieurs raisons. Il y a des raisons techniques (par exemple la portabilité) mais, encore plus important, il y a des raisons philosophiques. Debian est indépendante parce qu'elle n'est pas soutenue financièrement par une seule compagnie qui pourrait orienter ses décisions. De plus Debian est une "do-ocratie" (démocratie de ceux qui font) et une démocratie, ce qui est très inhabituel parmi les distributions "corporate". Enfin Debian propage ce que je nomme la culture de la liberté depuis 1993 et continue de le faire sans imposer aucun logiciel ou service non libre à ses utilisateurs ou à ses développeurs.
Pour moi tout ceci est une incitation puissante à choisir Debian par rapport à la plupart des autres distributions qui existent (et nous devrions tous garder en mémoire le fait que certaines des distributions les plus populaires reposent de façon importante sur le travail qui est fait dans Debian et qu'il leur serait très difficile de survivre sans Debian).
LinuxFr : Dans la dépêche LinuxFr annonçant ton élection, il est dit que le nombre de développeur Debian est au plus bas depuis 2003. Quelles sont les raisons données par ceux qui sont partis?
Stefano Zacchiroli : Affirmer que le nombre de développeurs à diminué depuis 2003, c'est juste ne pas avoir bien observé les données et ne pas connaître les détails. Nous avons eu une baisse brutale sur le papier lors des deux dernières années, mais c'est juste parce que le DAM (Debian Account Manager) a commencé à nettoyer vigoureusement les comptes anciens ou inutilisés. Il a contacté les gens et supprimé les comptes de ceux qui n'avaient ni voté, ni uploadé un paquet lors des deux dernières années. Donc, en fait, nous ne pouvons pas conclure à partir des données que la main-d'oeuvre a diminué. Nous avons simplement des chiffres officiels plus proches de la réalité.
À l'heure actuelle, nous avons environ 900 développeurs Debian (DD) et 120 mainteneurs Debian (DM). Nous sommes donc toujours aux alentours de 1000 personnes, avec l'avantage que la plupart des gens inactifs ne sont plus comptés. On peut donc arguer que notre main-d'oeuvre a en fait augmenté.
LinuxFr : Est-ce que l'introduction du nouveau statut de Debian Maintainer aux côtés de celui de Debian Developper est une bonne chose ?
Stefano Zacchiroli : Absolument ! Comme je l'ai dit au-dessus, les mainteneurs Debian (DM) font un travail important et maintiennent plusieurs paquets importants sans devoir se consacrer autant au projet que les développeurs Debian. En outre, même si je n'ai pas (encore) les chiffres pour le prouver, nous avons tous le sentiment que le fait de devenir DM est, pour de nombreuses personnes, un premier pas avant de devenir DD. Ainsi le rôle de DM sert de facto à diminuer la barrière à l'entrée pour maintenir des paquets de façon indépendante et aide aussi les gens enthousiastes à devenir des développeurs Debian.
LinuxFr : Si on ne parle pas anglais et qu'on ne sait pas programmer, comment aider quand même le projet Debian ?
Stefano Zacchiroli : C'est une question épineuse. Nous sommes bien conscients du fait qu'il est difficile de contribuer à Debian sans savoir parler anglais. Dans un monde idéal, n'importe qui pourrait contribuer à Debian dans sa propre langue et pour tous les types de contributions possibles. Malheureusement, cela nécessiterait d'énormes ressources de traduction qui nous font défaut actuellement.
Néanmoins, il est possible de contribuer au code sans connaître l'anglais car le code est le même pour tout le monde. Bien entendu, c'est plus difficile lorsque tous les autres contributeurs du code ne parlent qu'anglais. La communication avec eux devient plus difficile.
LinuxFr : En quoi le site http://debian.org reste-t-il à améliorer ?
Stefano Zacchiroli : L'aspect et le ressenti (look and feel) sont les points qui sont le plus souvent soulevés à ce propos. C'est en cours d'élaboration et nous avons déjà rendu disponibles certaines parties avec un nouveau look and feel. L'équipe web Debian mérite beaucoup de remerciements pour ce travail en cours et le délai est essentiellement le résultat du manque de main-d'oeuvre travaillant sur ce sujet. C'est plus facile de se plaindre que ce n'est pas encore fini plutôt que de chercher à comprendre ce qui provoque le retard.
Plus important encore, je crois que nous devrions nous servir du site pour expliquer encore plus en quoi Debian est unique dans le monde des distributions d'aujourd'hui. Je prévois de travailler sur ce sujet avec l'équipe web Debian, bien que je n'aie pas encore commencé à le faire.
LinuxFr : Est-il possible de se procurer un paquet source vierge du site web afin de faire des essais pour l'améliorer ?
Stefano Zacchiroli : Ce n'est pas packagé dans un paquet mais c'est maintenu dans un système de gestion de versions accessible pour les membres d'un groupe Alioth. Chaque développeur Debian peut facilement rejoindre ce groupe, ainsi que n'importe quel non DD qui a démontré qu'il était capable de contribuer (via des patchs sur le Bug Tracking System ou autres). Toutes les informations sur comment contribuer sont disponibles sur la page http://www.debian.org/devel/website/
LinuxFr : À quand le freeze de Squeeze ? À quand la sortie de la version finale de Squeeze ?
Stefano Zacchiroli : Du fait de mon délai pour répondre à cet entretien, Squeeze est maintenant gelée ! Cela a été annoncé durant la conférence Debian DebConf10 il y a quelques jours. Comme d'habitude nous sortirons la version définitive "quand elle sera prête", ce qui pour nous est une garantie de qualité. Nous ne sommes pas disposés à renoncer à la qualité des paquets pour pouvoir respecter des délais arbitraires.
Si nous travaillons tous ensemble (pas seulement les DD/DM mais aussi les contributeurs qui envoient des patchs), je crois que nous pourrons facilement sortir Squeeze lors du dernier trimestre 2010. Si les gens veulent aider, le meilleur moyen de le faire est de participer à la correction des bugs critiques qui affectent Debian Squeeze. Une liste facile à consulter est disponible ici.
LinuxFr : Est-il envisageable d'avoir des freezes qui soient périodiques (time based), même si la sortie de la stable reste en mode "quand c'est prêt" (when it's ready).
Stefano Zacchiroli : C'est un sujet "chaud" au sein de Debian et il est certain que nous en discuterons au début du cycle de sortie de Squeeze+1. C'est une question d'une grande portée sur laquelle nous voudrions d'abord avoir un accord de la part du Release Team et ensuite certainement un large consensus émanant des développeurs. À titre personnel, je pense que des gels périodiques (ce qui n'est pas la même chose que des sorties périodiques) seraient quelque chose de bien, pour la simple raison que cela permet aux développeurs de planifier à l'avance les grands changements. Mais encore une fois, c'est une discussion que nous aurons tous pour Squeeze+1 et au sujet de laquelle vous en entendrez sûrement plus dans les news.
LinuxFr : Quel sera le nom de la prochaine stable après Squeeze ?
Stefano Zacchiroli : Je ne sais pas. Le Release Team fait un travail très difficile et peu reconnu au sein de Debian, ce qui tend à attirer plus de controverses que de remerciements. Parmi les quelques privilèges amusants que ce team possède, il y a le fait d'avoir l'honneur de nommer les nouvelles versions. Habituellement le Release Team annonce ça au début du cycle donc personne ne connaîtra le nom avant la sortie de Squeeze. Si vous voulez le savoir plus tôt, peut-être devriez-vous aider à la sortie de Squeeze ?
LinuxFr : Le mandat de DPL d'un an n'est-il pas trop court ? Qu'est-ce qu'il est vraiment possible de faire en à peine un an ?
Stefano Zacchiroli : C'est une question difficile. J'en suis à peu près au tiers de mon mandat de Debian Project Leader et je suis d'accord qu'un an c'est court, principalement parce que ça prend du temps au début de comprendre le travail et de commencer à faire les choses efficacement. D'un autre côté nous sommes tous des volontaires et la tâche d'être le DPL est exigeante. Demander à des volontaires de faire ça pour plus d'un an pourrait effrayer des candidats potentiels. Je ne sais vraiment pas si une durée de mandat différente serait meilleure ou pire.
LinuxFr : À propos de Mancoosi, est-ce que ce projet a apporté quelque chose concrètement dans Debian ?
Stefano Zacchiroli : Bien entendu ma réponse ici est biaisée, mais je pense que oui. Mancoosi apporte plusieurs contributions à Debian. En premier lieu, nous maintenons plusieurs outils d'assurance qualité de l'infrastructure comme par exemple le paquet edos-debcheck (utilisé de façon routinière pour vérifier que l'archive ne contient pas de paquet non installable avant la sortie d'une version) ou le service http://edos.debian.net.
En outre, nous travaillons maintenant avec les développeurs du gestionnaire de paquets afin d'améliorer la qualité de la résolution des dépendances dans Debian (et dans d'autres distributions) en utilisant les technologies que nous avons développées dans Mancoosi comme CUDF. Les lecteurs qui s'intéressent à ce sujet doivent savoir qu'ils peuvent contribuer à cette initiative en rapportant (comme avec popcon) leurs problèmes de résolution de dépendances. Cela se fait via le paquet "mancoosi-contest" qui est disponible sur http://mancoosi.debian.net.
LinuxFr : Sans langue de bois, le projet Debian GNU/kFreeBSD est-il vraiment utile ? Combien de gens utilisent ça au lieu de choisir la vraie version FreeBSD ?
Stefano Zacchiroli : Je ne peux pas prédire le futur donc je ne sais vraiment pas combien d'utilisateurs vont choisir ça par rapport au "vrai" FreeBSD. Je ne pense pas non plus que cela a de l'importance. Debian est déjà assez unique pour la disponibilité des divers ports. Cependant, le fait que tous les ports officiels aient été basés jusqu'à présent sur Linux n'est pas un but en soi. Le but de Debian c'est de créer un système d'exploitation libre et il n'est écrit nulle part qu'il doive reposer seulement sur Linux. Évidemment, je ne pense pas que le plus populaire des noyaux Debian puisse changer de sitôt. Mais, en même temps, je suis bien conscient du fait qu'aujourd'hui, la version la plus répandue/fonctionnelle de GNU/Hurd c'est Debian GNU/Hurd, et j'en suis fier. De la même façon, je suis fier qu'il y ait une possibilité de sortir Squeeze, pour la première fois, avec deux ports non basés sur Linux mais sur kFreeBSD.
Après tout, n'oublions pas que nous sommes des volontaires et que nous travaillons pour le plaisir. C'est évident qu'il existe des volontaires compétents qui ont réussi à amener Debian GNU/kFreeBSD jusqu'à un état pouvant potentiellement permettre sa sortie. Bravo à eux !
Quant à l'évaluation de l'adoption de ces ports par les utilisateurs nous avons le temps... Mais une telle évaluation n'aurait pas été possible si les ports n'avaient pas été là en premier lieu !
LinuxFr : Si on regarde cette page de stats pour le noyau 2.6.34 [http://www.remword.com/kps_result/2_6_34_whole.html] on voit que Debian est seulement en 93ème position des contributeurs avec à peine cinq patchs. Est-ce la réalité ? Si non, comment inciter les développeurs Debian a rendre plus visibles leurs contributions ?
Stefano Zacchiroli : Cette question semble à première vue un peu trollifère :-)
Tout d'abord l'idée d'une comparaison entre les distributions créés par des sociétés et Debian est complètement injuste. Les compagnies ont des *employés* qui contribuent au noyau Linux alors que Debian a des *volontaires*. De plus l'argument moral selon lequel les entreprises "doivent" contribuer à Linux repose sur le fait qu'elles font de l'argent avec lui. Cet argument est trivialement non applicable à Debian.
Mais même si on laisse cela de côté, il est est clair que les contributions de Debian ne sont pas signalées de façon régulière sous le nom "Debian" (ce qui est OK puisque, encore une fois, Debian n'est pas une entreprise et donc les volontaires Debian sont libres de compter leurs contributions comme ils le souhaitent).
Je mentionne juste un exemple significatif : Ben Hutchings est un membre éminent de l'équipe noyau de Debian. Ses contributions sont - au moins pour les quelques exemples que j'ai vérifiés - comptées dans la catégorie "Hobbysts" et pas dans celle de Debian. Ben a contribué 17 patches pour le noyau 2.6.34, 12 pour le 2.6.32 et pour Linux 2.6.33 le nombre grimpe jusqu'à 38 patches.
Donc ces nombres sont bien jolis, mais ils conviennent seulement pour classer les entreprises dont les contributeurs sont, je suppose, *tenus* de mentionner leur compagnie dans leurs contributions.
Pour Debian, ce n'est pas le cas, mais cela ne signifie rien en terme d'évaluation des contributions au noyau Linux de l'équipe noyau de Debian.
LinuxFr : Quelle est la situation de Python au sein de Debian ? Au vu de http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573745 est-ce que la situation n'est pas bloquée ?
Stefano Zacchiroli : À mon humble avis la situation a plus avancé les six derniers mois que lors des quatre dernières années (ce n'est pas grâce à moi, mais grâce aux efforts de la communauté Python de Debian). Par exemple, les paquets python-defaults et python3-defaults, qui déterminent quelle est la version par défaut de l'interpréteur Python dans Debian, sont maintenant co-maintenus.
La situation des interpréteurs Python (versionnés) eux-mêmes est en effet bloquée et, comme tous les problèmes de relations entre les gens (social issues), ce n'est pas facile à résoudre.
Malheureusement, maintenant que le Comité Technique a été invoqué, tout ce que nous pouvons faire c'est d'attendre leur décision car le Comité est la plus haute autorité technique dans Debian. Seule une Résolution Générale peut passer outre le Comité ou décider à sa place.
LinuxFr : Dans ta plate-forme de candidature tu as indiqué: "Je lutterai contre la trop forte possessivité sur les paquets quand cela entre en conflit avec la qualité" (I will fight strong package ownership when it conflicts with quality). Quels sont les pouvoirs du DPL dans ce domaine ?
Stefano Zacchiroli : Tu as raison, il n'y a pas de pouvoir spécifique que le Debian Project Leader peut invoquer à ce sujet. Le seul non-pouvoir qui peut être utilisé est une plus grande popularité/consensus qui vient du fait que j'ai été élu sur une plate-forme qui contient cette déclaration. De toute façon, je crois que j'ai plus fait avancer cette question avant de devenir DPL avec ma campagne RCBW (Release Critical Bugs of the Week) qu'après.
L'idée clé, c'est qu'au sein de Debian nous avons vraiment besoin de généraliser notre culture et de réaliser que si nous voulons continuer à sortir des versions comme nous le faisons maintenant, nous avons besoin de plus de collaboration entre les mainteneurs de paquets. Les NMU (Non-Maintainer Uploads) sont des outils viables pour une telle collaboration. Ce sujet a été discuté à DebConf10 lors d'un meeting que j'ai organisé à ce propos. La vidéo est disponible ici.
LinuxFr : Plus généralement comment gérer les cas de développeurs non coopératifs au sein d'un projet communautaire ?
Stefano Zacchiroli : Dans ce sens général c'est une question à laquelle il est difficile de répondre. Au sein de Debian, nous sommes devenus meilleurs à ce sujet : encourager et accepter les NMU est le premier pas nécessaire. Si c'est accepté, alors il devient relativement facile de détecter les paquets qui sont négligés par leurs mainteneurs légitimes (il suffit de regarder les paquets qui sont maintenus essentiellement via plusieurs NMU d'affilée). À cette étape nous avons des procédures de transfert et d'assurance qualité que nous pouvons utiliser pour confier le paquet à ceux qui ont travaillé dessus lors des derniers uploads.
LinuxFr : Enfin dernière question. Maintenant que les micrologiciels (firmwares) posant des problèmes juridiques de redistribution sont séparés du noyau Debian, est-ce que le projet va chercher à être officiellement approuvé par la FSF comme par exemple gNewSense ?
Stefano Zacchiroli : C'est intéressant que tu poses cette question car j'ai discuté récemment avec les gens de la FSF et de gNewSenSe à ce sujet. Je partage ton point de vue que nous devrions travailler dans cette direction pour améliorer la relation entre Debian et la FSF. D'un autre côté, les gens de gNewSense sont très content de notre choix car cela va rendre leur travail plus facile.
LinuxFr : Merci beaucoup Zack d'avoir répondu à ces question. Et surtout merci Debian !
Aller plus loin
- Dépêche sur l'élection de Stefano Zacchiroli (7 clics)
- Le blog de Zack (3 clics)
- Sa plate-forme de candidature (2 clics)
- Le projet Debian (7 clics)
- Debian sur DMOZ (1 clic)
- DLFP : Debian Squeeze est gelée (3 clics)
# Original version (questions in french and answers in english)
Posté par patrick_g (site web personnel) . Évalué à 10.
There are contributions coming back, yes. Some of them can be followed using the (Debian) bug tracking system. For instance, at the end of the https://wiki.ubuntu.com/Debian/Usertagging wiki page there are a couple of interesting links, listing all (Debian) bug reports originating from Ubuntu, as well a similar listing of bug reports containing a patch coming from Ubuntu. Other examples of collaborations are "mixed" packaging team formed by both Debian and Ubuntu people. Does this mean that collaboration is perfect? Well, no. In principle Debian should expect to Ubuntu to give back all its work to Debian, in perfect fulfillment of a sane "upstream/downstream" relationship; but in principle we in Debian should be perfect in pushing changes to our upstreams and we are not. Let's say that we are starting to realize that and working together to decrease the "viscosity" of patch flow in all
directions.
Quelles sont, selon toi, les raisons de préférer Debian par rapport à Ubuntu ?
I've discussed the more general topic of the relevance of Debian in my recent talk "bits from the DPL" delivered at DebConf10 in New York, at the beginning of August (http://penta.debconf.org/dc10_schedule/events/569.en.html , video at http://meetings-archive.debian.net/pub/debian-meetings/2010/(...)
Debian is still unique among "mainstream" distributions for several reasons. There are some technical reasons (e.g. portability), but more important than that there are philosophical reasons. Debian is independent from money as it is not backed by any single company that can drive its decisions. Even more so, Debian is a do-ocracy and a democracy, which is quite peculiar among "corporate" distro. Finally, Debian has been spreading what I call the culture of freedom since 1993 and it is still doing that, without imposing non-free software or services to any of its users and developers. For me, this is a quite strong motive for choosing Debian over most other distros out there (and we should all keep in mind that some of the most popular distros out
there are heavily *based* on the work being done in Debian and that would have very hard time surviving without Debian)
Dans la dépêche annonçant ton élection [https://linuxfr.org//2010/04/18/26746.html] il est dit que le nombre de développeur Debian est au plus bas depuis 2003. Quelles sont les raisons données par ceux qui sont partis?
Claiming that the number of developers has decreased since 2003 is just a poor observation of data, without knowing the underlying details. We have had a sharp decrease *on paper* in the last 2 years, but that is just because DAM (the Debian Account Manager) has started to clean up old/unused accounts quite incisively, by pinging and then removing the accounts of people who have neither voted nor uploaded a package in the past 2 years. So, in fact, we cannot conclude from that data that people power have decreased, we have simply got the official numbers closer to reality.
As of today, we have about 900 DDs and 120 DMs (Debian maintainers), so we are pretty much in the same 1'000 ballpark numbers, with the advantage that most of the inactive people no longer figure in the count. Arguably then, our people power has increased.
Est-ce que l'introduction du nouveau statut de Debian Maintainer aux côtés de celui de Debian Developper est une bonne chose ?
Absolutely yes! As I've discussed above DMs are doing a lot of work and maintain several even important packages, without needing to be as committed to the project as DDs are. Additionally (even though I don't have [yet] numbers to back this out) we all have the feeling that becoming DM is for a lot of people a first step to become DD. Hence the role of DM is de facto reducing the contribution barrier to maintain packages independently and also help in getting more enthusiastic people becoming DD.
Si on ne parle pas anglais et qu'on ne sait pas programmer comment aider quand même le projet Debian ?
This is a tricky problem. We are well aware that there are problems in contributing to Debian without speaking English. In an ideal world, one should be able to contribute to Debian in her own language for every possible contributions, including bug reporting. Unfortunately arriving there would require a huge amount of translation people power, that we currently lack.
Nevertheless it is possible to contribute without knowing English, as code is code for everyone. Obviously, it is more difficult when all the other contributors of the code only speak English, as communicating with them becomes more difficult.
En quoi le site http://debian.org reste-t-il à améliorer ?
The look and feel is the most reported answer to this question. It is being worked on and we have already released some sub-site with a new look and feel. The debian-www team deserves lots of kudos for the ongoing work and the delay is essentially related to the lack of people power working on that stuff (it's way easier to complain it has not been done yet than actually getting to understand what are the blockers).
More importantly than that however, I believe we should use the website to explain more why Debian is unique in the distro world of today. I plan to work on that together with the debian-www team, although I haven't yet started doing that.
Est-il possible de se procurer un paquet source vierge du site web afin de faire des essais pour l'améliorer ?
It is not packaged in a standalone package, but maintained using version control system and appropriate alioth group. Every Debian Developer can easily join the group, as well as any non-DD which has shown she is able to contribute (via patches to the BTS or the like). All information on how to contribute can be found at http://www.debian.org/devel/website/
À quand le freeze de Squeeze ? A quand la sortie de la version finale de Squeeze ?
Thanks to my delay in replying to this interview, Squeeze is now frozen!, it has been announced during DebConf10 a few days ago. As
usual, it will be "released when it's ready", which for us is guarantee of quality: we are not willing to give up on package quality in order to meet some arbitrary deadline. If we all work together (not only DDs/DMs, but also contributors sending patches), I believe we can easily do that during 2010 Q4. If people would like to help, the best way to do that is helping fixing release critical bugs that are affecting Debian Squeeze; an easy to go through list is available at: http://bts.turmzimmer.net/details.php?bydist=squeeze&sor(...)
Est-ce qu'il est envisageable d'avoir des freeze qui soient périodiques (time based) même si la sortie de la stable reste en mode "quand c'est prêt" (when it's ready).
This is a very "hot topic" in Debian, that we will for sure discuss at the beginning of the release cycle of Squeeze+1. It is a far reaching topic, on which we would like to have agreement first of all from the Release Team and surely a large consensus in the developer body. Personally, I think that time-based freezes (which is not the same thing of time-based releases) is something good, for the simple reason that enable developers to plan in advance big changes. But again, this is a discussion for Squeeze+1 we will have all together and from which you'll surely hear back in the news.
Quel sera le nom de la prochaine stable après Squeeze ?
I don't know. The Release Team does a very hard and often thankless work in Debian, which tends to attract more flames thank kudos. Among the few fun privileges the Release Team enjoys, there is the honor of getting to choose release names. Usually, the Release Team announces that at the beginning of the release cycle, so nobody will know before the release of Squeeze. If you want to know earlier, you should help releasing Squeeze!
Est-ce que le mandat de DPL d'un an n'est pas trop court ? Qu'est-ce qu'il est vraiment possible de faire en à peine un an ?
This is a tricky question. I'm now at about 1/3 of my DPL term and I agree that 1 year is kind of short, mainly because it takes some time in the beginning to understand the job and start doing it efficiently. On the other hand we are all volunteers and the DPL work is quite challenging, asking volunteers to do that for more than 1 year might scary away potential candidates. I really don't know whether a different arbitrary length would be better or worse.
A propos de Mancoosi, est-ce que ce projet a apporté quelque chose concrètement dans Debian ?
Of course my answer on this is biased, but I argue that yes, Mancoosi is giving back quite some contributions to Debian. First of all we are maintaining several Quality Assurance infrastructure and tools, such as the edos-debcheck package (used routinely to check that the archive contains no uninstallable packages before a release) and the http://edos.debian.net services. Additionally, we are now working with package manager developers to improve the quality of dependency solving in Debian (and in other distros) by using technologies we have developer in Mancoosi such as CUDF. Readers interested in the topic should know that they can contribute to the initiative, by reporting (a-la popcon) their dependency solving issues via the "mancoosi-contest" package that can be found at http://mancoosi.debian.net.
Sans langue de bois est-ce que le projet Debian GNU/kFreeBSD est vraiment utile ? Combien de gens utilisent ça au lieu de choisir la vraie version FreeBSD ?
I can't predict the future, so I really don't know how many users will choose it over the "real" FreeBSD. Nor I think it does matter. Debian is quite unique already in its port availability. The fact that all official ports thus far have been Linux-based ports is however not a goal. Debian goals are to create free operating system and it is written nowhere that it should remain Linux-only. Obviously, I don't see the most popular Debian kernel changing anytime soon, but at the same time I'm well aware that the most widespread/functional port of GNU/Hurd today is Debian GNU/Hurd and I'm proud of that. On the same vein, I'm proud that there is a possibility of releasing Squeeze, for the first time, with 2 non-Linux ports that are kFreeBSD-based.
After all, let's not forget that we are volunteers and that we work for fun. It is evident that there are out there capable volunteers that did manage to bring Debian GNU/kFreeBSD to a potentially releasable state. Kudos to them! For the evaluation of user acceptance of those ports we have time ... but no such evaluation would have been possible if the ports weren't there in the first place!
Si on regarde cette page de stats pour le noyau 2.6.34 [http://www.remword.com/kps_result/2_6_34_whole.html] on voit que Debian est seulement en 93ème position des contributeurs avec à peine 5 patchs. Est-ce que c'est la réalité ? Si non comment inciter les développeurs Debian a rendre plus visibles leurs contributions ?
This question seem a bit trollish at first glance :-)
First of all the idea of a comparison among corporate distributions and Debian would be totally unfair, as companies have *employees* that contribute to the Linux kernel, while Debian has *volunteers*. Furthermore, the moral argument for which companies "have to" contribute to Linux is rooted on the fact that they make money with it; that argument is trivially non applicable to Debian.
But even if we let that go, it is clear that Debian contributions are not consistently reported under the name "Debian" (which is OK as, again, Debian is not a company, so Debian volunteers are free to do the accounting of their contribution as they please).
Just to mention a significant example, Ben Hutchings is a prominent member of the Debian kernel team. His contributions are, at least in the few examples I've checked, reported under the "Hobbysts" category rather than under the Debian one. For Linux 2.6.34 Ben has contributed 17 patches, 12 for 2.6.32, while for Linux 2.6.33 the number climbs up to 38 patches.
So, those numbers are nice, but are appropriate only to rank companies whose contributors are, I suppose, *expected* to mention the company in their contributions. For Debian this is not the case, but that means nothing in terms of how much the Debian kernel team contributes back to the Linux kernel.
Quelle est la situation de Python au sein de Debian ? Au vu de http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573745 est-ce que la situation n'est pas bloquée ?
In my humble opinion the situation has advanced more in the past 6 months than in the past 4 years (not for my merit, but thanks to the efforts of the Debian Python community). For instance, the python-defaults and python3-defaults packages, which determine which are the default Python interpreter versions in Debian, are now co-maintained.
The situation on the (versioned) Python interpreters themselves is indeed stuck, but as all social issues it is not an easy one to deal with. Unfortunately, now that the Technical Committee has been invoked, we can basically only wait for their decision, as the committee is the highest technical authority in Debian. Only a General Resolution can override the committee or decide in its place.
Dans ta plateforme tu as indiqué "I will fight strong package ownership when it conflicts with quality". Quels sont les pouvoirs du DPL dans ce domaine ?
You're right that there is no specific power the DPL can use for that. The only non-power that can be used is a relatively higher
popularity / consensus, coming from the fact that I've been voted on a platform containing that statement. Anyhow, I believe I've done more in that direction before becoming DPL with my RCBW campaign (see http://deb.li/rcbw for more info) than afterwords.
The key idea is that in Debian we really need to generalize our culture and realize that to continue releasing the way we are doing it now, we really need more collaboration among package maintainers and that NMU (Non-Maintainer Uploads) are a viable tool for such collaboration. This topic has been discussed at DebConf10 in a BoF I've organized on the subject (http://penta.debconf.org/dc10_schedule/events/609.en.html ,video at http://meetings-archive.debian.net/pub/debian-meetings/2010/(...)
Plus généralement comment gérer les cas de développeurs non coopératifs au sein d'un projet communautaire ?
In its generality, this is quite a tricky question to answer.
In Debian, we are getting better at that: encouraging and welcoming NMU is the first needed step. If that is accepted, then it becomes relatively easy to identify packages which are being neglected by their legitimate maintainers (e.g. it is enough to look for packages maintained essentially only via several NMUs in a row). At that point, we do have hijacking and QA procedures that we can use to pass the package to who has been working on it for the last uploads.
Maintenant que micrologiciels (firmwares) posant des problèmes juridiques de redistribution sont séparés du noyau Debian est-ce que le projet va chercher à être officiellement approuvé par la FSF comme par exemple gNewSense ?
It's interesting that you ask this question, as I've been discussing recently with both FSF people and gNewSense people of this matter. I share your point of view that we should work in that direction to improve the relationship among Debian and FSF. On the other hand, gNewSense folks are very happy of our choice as that will make their work easier.
[^] # You're so good with your kernel news, why this ?
Posté par dab . Évalué à -10.
Je pense , et je peux me tromper bien évidement, que ce post n'apporte pas grand-chose. En effet, les gens intéressés par la version originale iront naturellement la chercher ( sans grande difficulté) tandis que les autres ne trouveront pas réellement d'intérêt à ton post.
Sympathiquement.
[^] # Re: You're so good with your kernel news, why this ?
Posté par patrick_g (site web personnel) . Évalué à 10.
Heuuu...ou ça ? J'ai échangé des mails avec Zack, c'est dit dans l'introduction, donc je ne vois pas bien ou les anglophones iraient chercher la version originale.
J'avais fait la même chose à l'époque (poster la VO en commentaire) pour l'interview de Brad Spengler: http://linuxfr.org//2009/07/24/25761.html
[^] # Re: You're so good with your kernel news, why this ?
Posté par dab . Évalué à -9.
Vraiment désolé !
Mais pourquoi ne pas mettre ton premier post dans la news ?!?
[^] # C'est marrant ça
Posté par dab . Évalué à -10.
Il y a surement une bonne raison, resté 5 minutes pas 20, c'est ça ouais.
Bref, je croyais que le "nouveau" plussoiement pouvait éviter les first posts des auteurs des news, à priori non, faut bien se faire émoustiller un petit peu !?
Thanks.
[^] # Re: C'est marrant ça
Posté par BAud (site web personnel) . Évalué à 10.
oui, des gens vont se coucher passé minuit :-) en l'occurence, patrick_g n'est pas repassé depuis 0:21 d'après sa page, donc n'a pas vu (encore) ton post.
pouvait éviter les first posts des auteurs des news
C'est confondre un first post et un ajout légitime à la dépêche pour ceux préférant l'original en anglais, d'ailleurs expliqué par patrick_g "je ne vois pas bien où les anglophones iraient chercher la version originale".
C'est bien dommage de penser cela, d'autant que patrick_g< n'a pas vraiment besoin d'XP (il est deuxième avec 9184 là où tu n'en as que 18 avec ton compte de 2004 :/ et j'en ai 5163 en 4ème, vu que tu sembles exigent sur celui qui a la plus grosse...).
Je ne vois même pas pourquoi je te réponds, hormis que les "exigences" de transparence, apparaissant de-ci, de-là dernièrement, ont tendance à me faire trouver cela blessant pour ceux qui donnent un peu de leur temps sur ce site, ce qui pourrait amener certains à tourner 7 fois leur clavier avant de poster, mais est parfois oublié). Nous faisons, nous aussi, notre possible et au mieux la plupart du temps àmha.
[^] # Re: C'est marrant ça
Posté par toctoc1 . Évalué à 8.
C'est sûr que son commentaire n'amène rien...
Mais....
Moinsser Patrick_g, et avec une mauvaise raison, c'est l'acte ultime du Rebelle.
[^] # Re: You're so good with your kernel news, why this ?
Posté par patrick_g (site web personnel) . Évalué à 5.
Pas grave.
>>> Mais pourquoi ne pas mettre ton premier post dans la news ?!?
Le site c'est LinuxFr donc la VO n'a pas trop vocation à être dans le corps de la news...et puis cela aurait été trop long je pense. Là c'est disponible en commentaire pour ceux qui préfèrent l'original et pour les non francophones.
[^] # Re: You're so good with your kernel news, why this ?
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: You're so good with your kernel news, why this ?
Posté par patrick_g (site web personnel) . Évalué à 2.
Mais qui te dit que je n'ai pas déjà supprimé les mails ?
# Merci
Posté par Benoît . Évalué à 4.
# Squeeze=testing?
Posté par Gabin . Évalué à -6.
Mes souvenirs sont:
Sid < Squeeze/testing < freeze < stable
Sauf que je ne sais pas où mettre "unstable" :)
On ne pouvait pas se contenter des conventions?
pre-alpha
alpha
beta
delta
gamma
Quelqu'un peut-il me faire un rapide rappel, svp?
[^] # Re: Squeeze=testing?
Posté par tesiruna . Évalué à 9.
> pourquoi j'ai quitté Debian il y a 2ans.
Tu choisis la distribution que tu utilises en fonction de la facilité de
mémoriser le nom de leurs branches ?
L'avantage, c'est que si Ubuntu dois apprendre les nouveaux noms tous les six
mois, au moins Debian tu as quatre ans à chaque fois pour t'y faire.
[^] # Re: Squeeze=testing?
Posté par Gabin . Évalué à 0.
Je n'arrive jamais à savoir à quoi correspond telle branche, j'ai un bloquage sur ça.
J'ai bougé car c'était trop compliqué à suivre.
J'ai demandé gentillement un rappel, répond, si le tu peux, au lieu de me faire passer pour je ne sais quoi!
[^] # Re: Squeeze=testing?
Posté par vermillon . Évalué à 7.
Stable, testing et sid(=still in development=unstable) sont les trois "modes" possibles de la distribution.
Freeze désigne la période durant laquelle la transition des paquets de sid à testing est bloquée. Elle permet aux développeurs de corriger les derniers bugs important sans que de nouveaux n'apparaissent et ainsi préparer une sortie de version stable.
Une fois ces bugs corrigés, une copie de testing est faite et devient la nouvelle "stable" (ainsi à la sortie d'une release "stable", je suppose qu'on peut dire que stable est complètement égale à testing, mais juste à ce moment là).
Squeeze est le nom de la prochaine version stable (donc de l'actuelle version testing). Il y a eu comme précédentes stables des noms tels que Etch ou Woody. C'est le la seule chose qui varie en fonction du temps, tu peux en rester aux noms "stable, testing, sid" si ça te plait.
En espérant n'avoir pas dit de conneries. (pas parlé des paquets en "experimental")
[^] # Re: Squeeze=testing?
Posté par imr . Évalué à 3.
[^] # Re: Squeeze=testing?
Posté par Christophe Roland (site web personnel) . Évalué à 6.
[^] # Re: Squeeze=testing?
Posté par jyes . Évalué à 3.
Sid EST un perso de Toy Story, c'est le gamin qui casse les jouets ! D'où son utilisation pour la branche de développement (dans laquelle les dépendances peuvent être cassées).
[^] # Re: Squeeze=testing?
Posté par Le Pnume . Évalué à 4.
--->[]
[^] # Re: Squeeze=testing?
Posté par imr . Évalué à 2.
[^] # Re: Squeeze=testing?
Posté par Gof (site web personnel) . Évalué à 5.
[^] # Re: Squeeze=testing?
Posté par j_kerviel . Évalué à 2.
Malheureusement beaucoup de gens continuent de croire cette légende urbaine.
Rappelons donc que "still in developpement" est un Rétro-acronyme. Il a été trouvé à postériori, mais, originellement, il a juste été choisi pour le personnage (sid, l'enfant qui casse les jouets = instable, ça colle pas mal).
[^] # Re: Squeeze=testing?
Posté par BAud (site web personnel) . Évalué à 3.
juste sid ? sid c'est son nom, et c'est juste son prénom, c'est juste ?
[^] # Re: Squeeze=testing?
Posté par imr . Évalué à 3.
[^] # Re: Squeeze=testing?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Squeeze=testing?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
$ grep vicious /usr/share/dict/american-english
[^] # Re: Squeeze=testing?
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
$ grep ^vicious /usr/share/dict/words
vicious
viciously
viciousness/
[^] # Re: Squeeze=testing?
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
http://fr.wikipedia.org/wiki/Sly
[^] # Re: Squeeze=testing?
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Squeeze=testing?
Posté par Kerro . Évalué à 2.
Si c'est réellement l'unique raison... sans commentaires.
Il est vrai que le site web de Debian n'est pas clairement explicite à ce sujet. Ni même l'article Wikipedia, je viens de vérifier. Le novice est obligé de réfléchir et chercher un bon bout de temps pour savoir qui est quoi.
On trouve un bon début d'explication à un clic de la page d'accueil. Cependant ce n'est ni complet, ni parfaitement explicite. Il y a de l'auto-référence (pas bien), et la nécessité d'avoir déjà des bases sur la manière dont sont gérées les sorties des distributions. Ce n'est pas Michu-amical.
Mais bon, au lieu de critiquer, je ferai mieux de participer. Manque de bol c'est un poil élitiste pour une modification d'une page web Debian :-)
Ton système de lettres grecques n'est pas meilleur que stable/testing/unstable car il nécessite d'en connaître la signification traditionnelle en informatique (béta = pas prêt mais presque). Et puis l'ordre est exactement à l'opposé de l'utilisation habituelle (alpha indique en général quelque chose de très bien alors que gamma désigne déjà du nettement moins bon.
Au moins "stable" on devienne à peu près ce que ça veut dire.
[^] # Re: Squeeze=testing?
Posté par Gabin . Évalué à -10.
J'avoue ne jamais pouvoir me souvenir des dénominations des branches, c'est pourquoi j'ai quitté Debian il y a 2ans.Si c'est réellement l'unique raison... sans commentaires.
Vous craigniez, honnêtement!
Je pose une question et 2 emmerdeurs s'astiquent le troll.
[^] # Re: Squeeze=testing?
Posté par Maclag . Évalué à 3.
Sinon tu sous-entends qu'ils ne craignent plus.
2 - T'as arrêté Debian parce que tu ne sais pas te servir de Google?
L'information est incroyablement difficile à trouver:
- Wikipedia fr
- Wikipedia en
N'importe quel moteur de recherche.
C'est pas comme si c'était confidentiel et réservé à une élite de savoir comment les différentes Debian sont nommées.
Au concours de la mauvaise foi, tu éclates tout le monde ici...
[^] # Re: Squeeze=testing?
Posté par Gabin . Évalué à -5.
Il suffisait de répondre à la question, il n'y avait rien à supposer de mauvais ou je ne sais quoi.
Je n'ai pas arrêté que pour cela, mais ça me posait problème néanmoins à moi, je n'ai pas remis en question tout Debian pour autant.
[^] # Re: Squeeze=testing?
Posté par benoar . Évalué à 2.
Tu as raconté une idiotie, ça arrive, tu t'es fait remballer, accepte-le et arrête de t'enfoncer.
[^] # Re: Squeeze=testing?
Posté par Gabin . Évalué à -5.
Ton système de lettres grecques n'est pas meilleur que stable/testing/unstable car il nécessite d'en connaître la signification traditionnelle en informatique[mode on m'a pris pour un con]
Ah bah merde, je pensais que je faisais justement référence au cycle de developpement logiciel.
[fin mode]
Et puis l'ordre est exactement à l'opposé de l'utilisation habituelle (alpha indique en général quelque chose de très bien alors que gamma désigne déjà du nettement moins bon.
Effectivement, si on quitte le domaine du DEVELOPPEMENT LOGICIEL et une ou deux exceptions.
Vous êtes tellement enclin à vous foutre de la gueule des autres dés qu'on peut se poser une question ou deux naïves et pire sur Debian que ça en franchement triste!
Soignez-vous, sortez, rasez-vous, rencontrez de filles. (moi aussi je peux être condescendant)
[^] # Re: Squeeze=testing?
Posté par BAud (site web personnel) . Évalué à 6.
Visiblement, tu sais bien te prêter au jeu :-)
Perso, je ne l'avais pas interprété comme cela.
[^] # Re: Squeeze=testing?
Posté par imr . Évalué à 2.
[^] # Re: Squeeze=testing?
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Squeeze=testing?
Posté par tesiruna . Évalué à 4.
> > indique en général quelque chose de très bien alors que gamma désigne déjà du
> > nettement moins bon.`
>
> Effectivement, si on quitte le domaine du DEVELOPPEMENT LOGICIEL et une ou
> deux exceptions.
Non mais les appellations alpha/beta/etc sont des *releases* ou des *tags*.
Là on parle de branches. Et encore une fois il n'y a aucune difficulté, unstable
c'est instable, testing c'est la future release en cours de test, stable c'est
l'actuelle release.
> Vous êtes tellement enclin à vous foutre de la gueule des autres dés qu'on
> peut se poser une question ou deux naïves et pire sur Debian que ça en
> franchement triste!
>
> Soignez-vous, sortez, rasez-vous, rencontrez de filles. (moi aussi je peux
> être condescendant)
On est pas d'accord avec toi, on est des barbus puceaux ?
Vu la qualité de ta répartie, on pourrait aussi dire que tu ne dois pas avoir 20
ans.
[^] # Re: Squeeze=testing?
Posté par SQP . Évalué à 3.
Et déjà qu'il y a assez de monde pour confondre la stabilité des paquets avec la stabilité des programmes dedans, j'imagine pas ce que ca serait avec des "alpha" et "beta"
[^] # Re: Squeeze=testing?
Posté par tiot (site web personnel) . Évalué à 10.
[^] # Re: Squeeze=testing?
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 3.
Premier lien !
[^] # Re: Squeeze=testing?
Posté par Seb (site web personnel) . Évalué à 6.
unstable aura toujours comme nom de code Sid.
testing désigne la prochaine version stable, actuellement son nom de code est Squeeze.
stable est la version stable... qui se nomme actuellement Lenny.
Résumons :
stable -> Lenny
testing -> Squeeze
unstable -> Sid
Quand la prochaine version stable sortira (ici Squeeze) ça donnera :
stable -> Squeeze
testing -> [nom de jouet de Toy Story encore inconnu]
unstable -> Sid
Lenny sera alors qualifiée de "oldstable". Et cætera.
Pour plus de détails, tout est là : http://www.debian.org/doc/FAQ/ch-ftparchives.fr.html
[^] # Re: Squeeze=testing?
Posté par Gabin . Évalué à 1.
Encore un ou deux éclaircissement:
stable -> Lenny
testing -> Squeeze
unstable -> Sid
Donc, stable et testing prennent respectivement le nom de l'actuel et prochaine distro? (Perso de Toy Story)
Je pensais que "Squeeze" était un terme "debianneux" .
Et quid de d'"experimental"?
Est-ce une branche - j'imagine la toute première - ou est-ce également un synonyme à Sid?
[^] # Re: Squeeze=testing?
Posté par symoon . Évalué à 2.
« Experimental » est utilisée pour les paquets encore en cours de développement qui comportent des risques importants pour le fonctionnement de votre système. Elle est utilisée par les développeurs qui veulent étudier et tester les versions les plus récentes des logiciels. Les utilisateurs ne devraient pas utiliser ces paquets-là, car ils peuvent être dangereux et endommager les systèmes des utilisateurs même les plus expérimentés.
[^] # Re: Squeeze=testing?
Posté par patrick_g (site web personnel) . Évalué à 3.
Non c'est bien un personnage de Toy Story. Ce sont les aliens à 3 yeux : http://cinema.fluctuat.net/blog/44717-toy-story-histoires-de(...)
[^] # Re: Squeeze=testing?
Posté par Frédéric Lopez . Évalué à 3.
L'appellation « still in development » n'est en fait qu'un rétro-acronyme non officiel mais plutôt bien trouvé.
[^] # Re: Squeeze=testing?
Posté par imr . Évalué à 1.
[^] # Re: Squeeze=testing?
Posté par Sylvain Sauvage . Évalué à 4.
Et puis cela n’a rien à voir.
Stable est la branche que l’on ne touche que pour corriger des bogues, c’est ce qui est distribué et numéroté/nommé.
Unstable et Testing sont les branches de développement où Unstable est toujours en développement et Testing, la branche de préparation de la nouvelle Stable.
Alors que les termes alpha et bêta (ou rc1, rc2…) sont des qualifications que l’on donne aux versions prêtes à être distribuées, en pré-distribution pour augmenter l’assiette de test. Pour Debian, cela correspond à Testing en mode « frozen », la date indiquant la progression (il y a tellement de paquets qui avancent en même temps qu’il serait illusoire de vouloir nommer un moment précis en rcN ou en lettre grecque, surtout quand la période de freeze peut durer plusieurs mois).
Avant, Testing s’appelait Frozen et n’existait pas en dehors de la période de gel (ce qui se fait dans le développement classique). Ça a changé parce que la création de Frozen prenait beaucoup de temps et que ça bloquait Unstable.
# Debian sort les firmware du noyau
Posté par Christian Foucher . Évalué à 1.
Je me pose la question de pourquoi Linus Torval dans le noyau officiel continue à distribuer ces firmwares?
http://linuxfr.org/forums/15/29093.html
Personnellement, je préférais qu'ils soient packager sur une source externe (comme debian-multimedia par exemple), et installable par apt-get.
[^] # Re: Debian sort les firmware du noyau
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Parce que pour lui, les firmwares, n'étant pas destinés à être exécutés par le processeur principal de l'ordinateur, ne sont pas soumis aux mêmes règles que les logiciels.
Personnellement, je préférais qu'ils soient packager sur une source externe (comme debian-multimedia par exemple), et installable par apt-get.
Ça tombe bien : avec la prochaine Debian, ce sera précisément le cas.
[^] # Re: Debian sort les firmware du noyau
Posté par BAud (site web personnel) . Évalué à 4.
http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmwa(...)
pour quelques matériels, je ne me rappelle pas avoir vu passer de dépêche sur cette initiative (peut-être une que j'ai raté sur LWN :/).
Grâce à hicham de fedora, celui pour ueagle-atm (les modems sagem fast800) a pu être mis en ligne de manière pérenne
http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmwa(...)
même si seulement le dernier avait une licence permettant la distribution (une BSD-like, code source non fourni :/), les précédents sont aussi disponibles. Ça va me permettre d'envisager de fermer http://eagle-usb.org après plus de 7 ans de bons et loyaux services :D (le modem est encore utilisé dans quelques pays comme l'algérie :/).
Les travaux de Debian autour de firmware-class (module permettant d'extraire le firmware du code source de pas mal de pilotes pour le charger "à la volée" à partir d'un fichier) ont beaucoup apporté àmha à de nombreux pilotes qui avaient tendance à coder le firmware comme un tableau en blob planté dans un .h... Je me rappelle des travaux de l"époque pour recenser les firmwares non libres dans les différents sources de modules du noyau... Ceci a permis de rationaliser leur gestion àmha (même si j'entends encore les cris d'orfraies des "pragmatiques" de l'époque...).
Parce que pour lui, les firmwares, n'étant pas destinés à être exécutés par le processeur principal de l'ordinateur, ne sont pas soumis aux mêmes règles que les logiciels.
même si cela peut être vu comme "moins important", un firmware n'en reste pas moins du logiciel et pourrait mériter qu'on s'y intéresse en libre àmha (il y a pleins de compilateurs pour pleins de DSP et autres simili-processeurs...), que ça soit moins prioritaire, pourquoi pas, mais je ne souhaite pas reprendre le débat qui m'avait pris pas mal de temps à suivre sur debian-legal ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.