Bon tout ça c'est bien joli mais gagner de l'argent d'une façon aussi ignominieuse, même si on en dépense une partie pour des bonnes causes, ça reste méprisable.
>>> Et pourquoi ont-ils choisit la licence BSD plutôt que leur licence GPL ?
Il y a confusion. C'est juste le bout de code antédiluvien (Sun RPC) intégrée à la Glibc qui a changé de licence. Il était sous une licence baroque non libre et maintenant il est sous BSD.
Je suis au boulot avec mon laptop sous WinXP et comme j'avais 30 min à attendre sans pouvoir bosser j'ai décidé de faire un petit comparatif des performances javascript entre Chrome, Firefox stable et Firefox 4 Beta.
>>> A chaque fois que j'entends parler de theo de raadt, j'ai l'impression qu'il envoie toujours chier les gens qui bossent sur son projet, et qu'il agit comme un dictateur qui pète plus haut que son cul (pour rester poli).
Je crois que les devs savent tous que Theo gueule facilement et qu'ils ne s'en préoccupent pas plus que ça. Contribuer à ce projet implique d'avoir le cuir épais. Si ça rebute certaines personnes ben tant pis pour elles.
Je crois que celui qui a fait le meilleur résumé de la situation c'est J.C. Roberts sur ce post d'Undeadly : http://www.undeadly.org/cgi?action=article&sid=201007211(...)
"When people actually care about something, they tend to have strong opinions. When you are wrong, you hear about it, very directly and in no uncertain terms. Absolutely no one is given special treatment. You have a choice between being offended and leaving, or appreciating the criticism and trying to do better. The people who get offended are the ones who have missed the obvious; another person just gave you their time in writing out their opinion and correction. They may have skipped showering you with sunshine, rainbows and ponies, but how you feel is unimportant. The thing that matters is the thing they care about, the best way to do it.
For the unfamiliar and across cultural/language boundaries, this approach can seem very abrupt at first, but if you look at it pragmatically, you'll see it is highly effective and efficient. On a long enough timeline, the survival rate for everyone drops to zero, so time is the limiting factor for everyone. When you view this macabre observation in the context of the very limited free time available for fun hacking, you'll finally understand why communications tend to be very direct and terse. ".
>>> je croyais que le fairplay sur DLFP consistait à ne pas divulguer les IPs
Tu es conscient que je ne fais que relater une histoire qui s'étale déjà sur la mailing list publique d'OpenBSD ?
Tu as cliqué sur l"hyper lien que j'ai mis derrière la phrase "l'astuce qui a été utilisée par David Hill" ? Cela t'envoie directement vers le mail explicatif complet de David Hill qui contient l'IP et le nom de Wim.
Comme son explication n'était pas encore assez complète pour certains le développeur Ropers a posté un autre message qui décortique encore plus l'astuce : http://www.mail-archive.com/misc@openbsd.org/msg94269.html
Donc il n'y a aucun secret. Une recherche Google.com sur 83.101.24.229 donne d'ailleurs, dans ses deux premiers résultats, un lien vers le thread OpenBSD.
Le fait de passer ce lien purement privé "à quelqu'un d'autre de la communauté" démasque également le troll puisqu'il n'y a que lui que l'a reçu.
Si Wim veut jouer cette carte là pour se défendre alors il doit dire qui lui a envoyé le lien (et produire l'email en question).
Si Wim avait été malin il aurait utilisé la fonction de prévisualisation des tinyurl.
En allant sur http://preview.tinyurl.com/2uhlqpy il aurait pu voir sur quoi pointait le lien et il se serait bien gardé de cliquer.
Et donc tous les vêtements de la planète sont produits en Chine par des petits enfants ? Aucun autre pays au monde ne produit de tshirts dans des conditions normales ?
Pareil quand tu veux commander un tshirt personnalisable. Souvent les sites proposent des interfaces uniquement en flash pour l'étape de personnalisation.
>>> 'IGP intel, intégré aux processeurs i3/i5. L'IGP est bien moins gourmand en énergie que le GPU nVidia, mais n'est pas capable de faire du décodage performant de vidéo HD
>>> Désolé, je n'avais pas vu que tu étais l'auteur de la news et le premier posteur ...
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.
>>> les gens intéressés par la version originale iront naturellement la chercher (sans grande difficulté)
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
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?
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.
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.
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.
[^] # Re: Le sens de la vie
Posté par patrick_g (site web personnel) . En réponse au journal [Brevets] C'est Paul Allen qui a la plus grosse !. Évalué à 5.
http://en.wikipedia.org/wiki/Paul_allen#Philanthropy
Dans la liste des trucs, je trouve que le plus intéressant c'est le Allen Telescope Array qui est construit en grande partie pour la recherche SETI :
http://en.wikipedia.org/wiki/Allen_Telescope_Array
Bon tout ça c'est bien joli mais gagner de l'argent d'une façon aussi ignominieuse, même si on en dépense une partie pour des bonnes causes, ça reste méprisable.
[^] # Re: Langage D
Posté par patrick_g (site web personnel) . En réponse à la dépêche Fedora 14 en version alpha. Évalué à 2.
[^] # Re: Le seul dans ce cas
Posté par patrick_g (site web personnel) . En réponse au journal La FSF libère la glibc!. Évalué à 10.
Il y a confusion. C'est juste le bout de code antédiluvien (Sun RPC) intégrée à la Glibc qui a changé de licence. Il était sous une licence baroque non libre et maintenant il est sous BSD.
[^] # Re: Benchmark sur les performances Javascript
Posté par patrick_g (site web personnel) . En réponse à la dépêche Firefox 4 bêta disponible pour tests (et plus si affinités). Évalué à 3.
# Benchmark sur les performances Javascript
Posté par patrick_g (site web personnel) . En réponse à la dépêche Firefox 4 bêta disponible pour tests (et plus si affinités). Évalué à 9.
Hardware :
- Intel Core 2 Duo 2.26 GHz
Versions des logiciels :
- Firefox 3.6.8 (version stable)
- Firefox 4 Beta4 (version de dev)
- Chrome 5.0.375.127 (version stable)
- Chrome 7.0.503 (version de dev)
Benchmarks:
- SunSpider
- V8 Benchmark v5 (attention ce bench est d'origine Google)
- Dromaeo Javascript (attention ce bench est d'origine Mozilla)
Résultats:
SunSpider Firefox 3.6.8 (version stable) => 2196 ms
SunSpider Firefox 4 Beta4 (version de dev) => 1403 ms
SunSpider Chrome 5.0.375.127 (version stable) => 568 ms
SunSpider Chrome 7.0.503 (version de dev) => 555 ms
V8 Firefox 3.6.8 (version stable) => 488 points
V8 Firefox 4 Beta4 (version de dev) => 1091 points
V8 Chrome 5.0.375.127 (version stable) => 4718 points
V8 Chrome 7.0.503 (version de dev) => 5370 points
Dromaeo Firefox 3.6.8 (version stable) => 95,23 runs/s
Dromaeo Firefox 4 Beta4 (version de dev) => 329.58 runs/s
Dromaeo Chrome 5.0.375.127 (version stable) => 330.08 runs/s
Dromaeo Chrome 7.0.503 (version de dev) => 478.03 runs/s
Interprétation:
Firefox 4 est vraiment une belle avancée par rapport à la version 3.6...mais le chemin pour rattraper Chrome est encore long.
[^] # Re: Plus pour moi
Posté par patrick_g (site web personnel) . En réponse au journal Vala LaTeXila 1.99, environnement LaTeX intégré en GTK. Évalué à 9.
Je te conseille plutôt de te ficher complètement de la note que tes commentaires obtiennent. Tu verra que la vie te semblera plus gaie !
[^] # Re: élégant
Posté par patrick_g (site web personnel) . En réponse au journal OpenBSD et le piège à troll. Évalué à 3.
Je ne connaissais pas et ça m'a paru astucieux.
[^] # Re: Une ch'tite question sur Theo
Posté par patrick_g (site web personnel) . En réponse au journal OpenBSD et le piège à troll. Évalué à 9.
z'ont pourtant pas l'air malheureux les devs OpenBSD : http://www.undeadly.org/cgi?action=article&sid=201007250(...)
Je crois que les devs savent tous que Theo gueule facilement et qu'ils ne s'en préoccupent pas plus que ça. Contribuer à ce projet implique d'avoir le cuir épais. Si ça rebute certaines personnes ben tant pis pour elles.
Je crois que celui qui a fait le meilleur résumé de la situation c'est J.C. Roberts sur ce post d'Undeadly : http://www.undeadly.org/cgi?action=article&sid=201007211(...)
"When people actually care about something, they tend to have strong opinions. When you are wrong, you hear about it, very directly and in no uncertain terms. Absolutely no one is given special treatment. You have a choice between being offended and leaving, or appreciating the criticism and trying to do better. The people who get offended are the ones who have missed the obvious; another person just gave you their time in writing out their opinion and correction. They may have skipped showering you with sunshine, rainbows and ponies, but how you feel is unimportant. The thing that matters is the thing they care about, the best way to do it.
For the unfamiliar and across cultural/language boundaries, this approach can seem very abrupt at first, but if you look at it pragmatically, you'll see it is highly effective and efficient. On a long enough timeline, the survival rate for everyone drops to zero, so time is the limiting factor for everyone. When you view this macabre observation in the context of the very limited free time available for fun hacking, you'll finally understand why communications tend to be very direct and terse. ".
[^] # Re: élégant
Posté par patrick_g (site web personnel) . En réponse au journal OpenBSD et le piège à troll. Évalué à 10.
[^] # Re: Je trouve...Le fait de passer ce lien privé
Posté par patrick_g (site web personnel) . En réponse au journal OpenBSD et le piège à troll. Évalué à 6.
Tu es conscient que je ne fais que relater une histoire qui s'étale déjà sur la mailing list publique d'OpenBSD ?
Tu as cliqué sur l"hyper lien que j'ai mis derrière la phrase "l'astuce qui a été utilisée par David Hill" ? Cela t'envoie directement vers le mail explicatif complet de David Hill qui contient l'IP et le nom de Wim.
Comme son explication n'était pas encore assez complète pour certains le développeur Ropers a posté un autre message qui décortique encore plus l'astuce : http://www.mail-archive.com/misc@openbsd.org/msg94269.html
Donc il n'y a aucun secret. Une recherche Google.com sur 83.101.24.229 donne d'ailleurs, dans ses deux premiers résultats, un lien vers le thread OpenBSD.
[^] # Re: Je trouve...Le fait de passer ce lien privé
Posté par patrick_g (site web personnel) . En réponse au journal OpenBSD et le piège à troll. Évalué à 4.
Si Wim veut jouer cette carte là pour se défendre alors il doit dire qui lui a envoyé le lien (et produire l'email en question).
[^] # Re: URL raccourcie
Posté par patrick_g (site web personnel) . En réponse au journal OpenBSD et le piège à troll. Évalué à 8.
En allant sur http://preview.tinyurl.com/2uhlqpy il aurait pu voir sur quoi pointait le lien et il se serait bien gardé de cliquer.
[^] # Re: Tout ça pour du flash ?
Posté par patrick_g (site web personnel) . En réponse à la dépêche Gnash en 0.8.8 : Youtube et le matériel d'abord. Évalué à 6.
[^] # Re: Une opinion
Posté par patrick_g (site web personnel) . En réponse au journal Où l'on trolle sur la médaille Fields.. Évalué à 3.
[^] # Re: Tout ça pour du flash ?
Posté par patrick_g (site web personnel) . En réponse à la dépêche Gnash en 0.8.8 : Youtube et le matériel d'abord. Évalué à 4.
[^] # Re: Un jeu libre! (et pas seulement un moteur...)
Posté par patrick_g (site web personnel) . En réponse à la dépêche Braldahim, Jeu Web Libre. Évalué à 3.
[^] # Re: Bon ben...
Posté par patrick_g (site web personnel) . En réponse au journal De l'écriture d'un pilote Linux pour un gadget - suite. Évalué à 2.
Bien entendu c'est déjà prévu et ce sera l'objet d'une brève.
[^] # Re: Empathy, Gajim, Pidgin
Posté par patrick_g (site web personnel) . En réponse au journal google chat: enfin une solution vidéo aboutie pour les distributions les plus répandues (debian et ubuntu). Évalué à 2.
[^] # Re: You're so good with your kernel news, why this ?
Posté par patrick_g (site web personnel) . En réponse à la dépêche Entretien avec Stefano Zacchiroli, Responsable du Projet Debian. Évalué à 2.
Mais qui te dit que je n'ai pas déjà supprimé les mails ?
[^] # Re: Squeeze=testing?
Posté par patrick_g (site web personnel) . En réponse à la dépêche Entretien avec Stefano Zacchiroli, Responsable du Projet Debian. É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(...)
# Décodage vidéo
Posté par patrick_g (site web personnel) . En réponse au journal nVidia Optimus, bonne idée fondamentalement incompatible avec Linux.... Évalué à 10.
Ah si depuis le noyau 2.6.35, l'IGP Intel des i3/i5/i7 peut assurer le décodage matériel des formats H.264 et VC1 : http://linuxfr.org/2010/08/02/27164.html#bref6
[^] # Re: You're so good with your kernel news, why this ?
Posté par patrick_g (site web personnel) . En réponse à la dépêche Entretien avec Stefano Zacchiroli, Responsable du Projet Debian. É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: ça va pas être un peu lent?
Posté par patrick_g (site web personnel) . En réponse à la dépêche Le client F2F libre OneSwarm sort en version 0.7. Évalué à 7.
C'est vrai ça ? Je comprend qu'il n'y a pas vol avec effraction mais je ne vois pas comment on peut dire qu'il n'y a pas vol tout court.
[^] # Re: You're so good with your kernel news, why this ?
Posté par patrick_g (site web personnel) . En réponse à la dépêche Entretien avec Stefano Zacchiroli, Responsable du Projet Debian. É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
# Original version (questions in french and answers in english)
Posté par patrick_g (site web personnel) . En réponse à la dépêche Entretien avec Stefano Zacchiroli, Responsable du Projet Debian. É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.