patrick_g a écrit 6453 commentaires

OK Merci. Moi j'attendais le freeze pour abandonner ma vieille Hardy Heron et faire le saut.

Aucun rapport avec le fil mais je profite de ta présence. Je viens de voir que Squeeze était en freeze depuis aujourd'hui. J'ai également vu que tu étais parmi les mainteneurs de la formation Debian GNU/Linux : http://formation-debian.via.ecp.fr/

Est-ce qu'il y a déjà une version de la formation adaptée à Squeeze qui est dispo quelque part ?

Merci pour le lien. Le post d'Adam Williamson est extrêmement intéressant à lire et j'invite tout le monde à aller le voir.

>>> Marrant de venir sur un site de libristes, particulièrement un vendredi

On avait la news dans le pipe depuis mardi mais, pour la publier, on a attendu un jour qui nous paraissait particulièrement approprié ;-)

Pour apporter de l'eau à ton moulin cet exemple qui concerne PulseAudio: http://thread.gmane.org/gmane.linux.redhat.fedora.devel/1371(...)

En gros on reproche au mainteneur de PulseAudio (Lennart Poettering) de ne pas passer assez de temps à corriger les bugs ouverts dans le bugzilla. Sa réponse c'est que, selon ses comptes, il y a seulement 3 développeurs payés à plein temps pour bosser sur l'infrastructure audio de Linux (y compris lui) donc ils font ce qu'ils peuvent.
Et il ajoute la flèche du Parthe:

"One would wish that a certain other company with a clear focus on desktop Linux (where consumer audio is a key part of) would want to actually hire more folks in this area, but well, ..."

Ouf ! Je craignais un peu que mon appât ait été déployé en vain mais finalement ça a mordu ;-)

Plus sérieusement je suis d'accord avec presque tout ce que tu écris MAIS je pense que tu n'as pas compris ma position. J'ai sans doute dû mal m'exprimer.
Je ne dis pas que c'est une obligation de libre que de contribuer upstream. Je dis juste que c'est "courtois" ou bien "amical" de le faire (c'est dur de trouver un adjectif approprié).
Prenons un exemple: un type veut entrer dans une pièce. Il arrive devant la porte d'entrée juste en même temps qu'une autre personne. Il est "courtois" de ne pas s'engouffrer en premier et, au contraire, de tenir la porte pour que l'autre personne entre en premier.
Ce n'est pas illégal, ce n'est pas immoral, ce n'est même pas "non éthique", de passer en premier. C'est juste discourtois. Cela montre qu'on pense à soi sans penser aux autres.

Si les développeurs salariés par Canonical produisent du code pour leur distro sans songer à travailler avec l'upstream alors ce n'est pas illégal, ce n'est pas immoral, ce n'est même pas "non éthique".
C'est juste discourtois. Cela montre qu'ils pensent à leurs users sans penser aux autres users.

En outre on sait très bien que la solution la plus efficace c'est d'écrire du code pour l"upstream puisque ce code sera utilisé et testé par bien plus de monde que du code spécifique distro.

s/un modèle d'entraide est de partage/un modèle d'entraide et de partage

>>> canonical fait largement mieux que tous les autres.

OK pour Red Hat (belle démonstration) mais par rapport à Fluendo, Collabora, Lanedo, Openismus, CodeThink ?
Si je regarde par exemple Lanedo je constate qu'elle a plus du double de commits par rapport à Canonical alors que, selon le site web, le projet n'existe que depuis 5 ans (soit moins que Canonical) et emploie 10 personnes en tout (dont une secrétaire).

>>> Et comme ils ne sont pas contraints de le faire, tout va très bien madame la marquise.

Personne n'a dit ni même sous-entendu que Canonical était contrainte de contribuer à l'écosystème global. Ce n'est pas une question d'obligation juridique, de licence ou de quoi que ce soit.
C'est juste que, à la base, le logiciel libre c'est un modèle d'entraide est de partage donc il est normal que la pression sociale s'exerce pour que chacun contribue dans la mesure de ses moyens et en fonctions de ses capacités.
Personne ne va reprocher à des projets bénévoles de type Gentoo ou Debian de ne pas avoir beaucoup de contributions.
En revanche pour le projet Ubuntu qui est ultra populaire et qui est porté par Canonical (une entreprise privée qui paye des développeurs et qui est dirigé par un milliardaire favorable au libre) cela paraîtrait normal de contribuer à l'écosystème du libre.
Si cette contribution est faible (*) alors je trouve normal d'exercer une pression sociale pour l'inciter à contribuer plus au pot commun.

*: Modulo les calculs d'Alenvers plus haut.

Bon puisque personne ne se lance (en dépit des 210 commentaires du journal précédent: http://linuxfr.org/~IsNotGood/30002.html ) j'y vais.

Pourquoi Canonical contribue aussi peu ? Selon le pdf ils sont à seulement 1,03% des commits soit un total de 4487.
Ils sont dépassés par des multinationales titanesques ayant des légions de codeurs comme Lanedo ou Openismus ou encore Codethink.

Je me souviens que lors de la controverse de 2008 au sujet des contributions de Canonical au noyau Linux (quasi inexistantes), il avait été répondu que, certes ils ne travaillaient pas sur le noyau, la GlibC ou GCC, mais que les commits de Canonical se faisait essentiellement dans les couches hautes de l'écosystème comme GNOME.
A l'époque j'avais écrit ça dans le journal [http://linuxfr.org/~patrick_g/27223.html] :

"En ce qui concerne la réponse expliquant que le travail se déroule sur Gnome et pas sur le noyau, il va falloir prouver cette assertion en pointant des patchs dans les CVS et pas seulement se contenter d'assener ça sans aucune preuve".

Maintenant que nous avons une étude sur les commits de Gnome on voit bien que la parade rhétorique de 2008 était un mensonge éhonté.
Je ne sais pas si le nombre de commits est une mesure représentative des contributions mais si c'est le cas alors il semble bien que Canonical ne contribue pas du tout à la mesure de sa popularité parmi les GNU/Linuxiens.

Pour un contrepoint à l'analyse de GNOME Census voir la réponse de Jono Bacon ici: http://www.jonobacon.org/2010/07/30/red-hat-canonical-and-gn(...)
Jono ne remet pas en cause les chiffres du rapport mais il affirme qu'il est incomplet. Selon lui Canonical ne contribue certes pas beaucoup à GNOME en upstream mais contribue beaucoup à d'autres projets liés à GNOME :

"Contributions (..) not part of official GNOME modules, and hosted and developed elsewhere, such as Launchpad".

Pour moi, mais je suis peut-être méchant, cela ressemble beaucoup à des projets spécifiques Ubuntu qui ne remontent pas en upstream. C'est justement ce que l'on reproche à Canonical quand on dit qu'ils ne contribuent pas à l'écosystème global.

Il y a beaucoup plus de détails ici : http://lwn.net/Articles/395895/

Ce serait vraiment bien si quelqu'un qui s'y connait un peu proposait une news sur les divers modules de sécurité de noyau pour les comparer (SMACK, SELinux, TOMOYO, bientôt AppArmor).
Ce serait un excellent sujet je pense.

Je crois que Zarmakuizz cherchait la contrepèterie à faire avec "prétérition" et pas la définition du mot.

Corrigé. Merci d'avoir relevé la faute.

>>> Merci pour le lien, l'article de Jonathan Corbet est en effet très clair et je comprends un peu mieux le mécanisme.

C'était aussi le premier hyperlien du paragraphe sur le patch de compactage mémoire ;-)

>>> Donc, ai-je loupé une subtilité ?

Non je ne pense pas. Il faut voir que les pages non déplaçables sont relativement rares donc ton premier exemple se produira rarement.
Concernant le second je ne vois pas de faille et donc je te réponds que je ne sais pas :)
A mon avis on est dans le cas indiqué par Mel Gorman ou un algo plus sophistiqué (qui traiterait ce genre de cas) ne vaudrait pas le coup:

"This method is a bit primitive but is easy to understand and greater sophistication would require maintenance of counters on a per-pageblock basis. This would have a big impact on allocator fast-paths to improve compaction which is a poor trade-off".

Je t'invite à lire tout son mail de commit qui est très détaillé (avec des benchs plus complets que ce que j'ai indiqué) : http://article.gmane.org/gmane.linux.kernel.mm/47298

La coquinerie c'est le lien mis sous "les développeurs d'OpenBSD" ;-)
C'est tiré de là : http://undeadly.org/cgi?action=article&sid=2010072509351(...)

Dans le lien "Le bilan des changements partie 3" il y a juste cette phrase concernant les patchs qui n'ont pas été intégrés:
"The fanotify file notification interface did not go in, despite the lack of public opposition".

Le truc c'est que le second scanneur ne se contente pas de lister les pages libres :
"il recherche toutes les pages libres susceptibles d'accueillir des données. Quand il en trouve, il y déplace les pages listées dans la migrapages.

Regarde les graphiques de l'article LWN et ça deviendra plus clair :
http://lwn.net/Articles/368869/

On voit bien qu'à la fin du run toutes les pages du début de la zone sont vides et toutes les pages de la fin de la zone sont pleines.

>>> je sais pas s'il fait un total

Non je ne fais pas de total mais ça se compte facilement en dizaines d'heures.
C'est dur de tenir le rythme des devs Linux avec une release tous les 3 mois.

Arf et on a laissé passer ça à la relecture :-/
Corrigé.

C'est clair que j'ai pensé à lui en me trompant de prénom.

Bien vu, merci. J'ai corrigé la news.

>>> Pff trop long tout ça, désolé.

Mais extrêmement intéressant, donc merci !

s/pour l'acronyme DSTD/pour l'acronyme DSDT

C'est bizarre mais sur le net on trouve deux explications pour l'acronyme DSTD.
- Soit "Discrete System Descriptor Table".
- Soit "Differentiated System Description Table".

Quelqu'un pour se palucher la norme ACPI afin de nous dire ce qui est juste ?