patrick_g a écrit 6397 commentaires

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 ?

Le public n'est peut-être pas le même. J'ai entendu dire qu'il y avait 5 fois plus de gens abonnés au flux des dépêches qu'un flux des journaux. Donc ça se justifie de promouvoir ainsi les bons journaux non hors-sujets.
Ce que tu voudrais c'est un transfert des commentaires du journal dans la news ?

Fait. Merci pour les remarques.

>>> la tirade de patrick_g est juste.

Par "la tirade de patrick_g" tu entends quoi exactement ?
Si c'est à la NdM que tu fais allusion...ben....comme son nom l'indique je n'en suis pas l'auteur. C'est un modéro qui l'a ajouté pour compléter la news.

Si c'est une vraie modif OK je suis d'accord mais si c'est juste pour corriger une typo je ne vois pas l'intérêt de laisser une trace.
Tu imagines un journal qui se terminerai par:

NdM 11h32 : Ajout d'un s final au mot "périphérique".
NdM 11h42 : Majuscule au début de la phrase "Quant à pax".
NdM 13h06 : Remplacement de "que format tar" par "au format tar".

Ce serait ridicule. Et puis les news noyau doubleraient de taille après inclusion de la liste des corrections de fautes ;-)

A moins que je n'ai mal compris ton besoin il me semble qu'Avidemux pourrait parfaitement faire l'affaire.
Pour supprimer ce qui ne m'interesse pas dans une vidéo je fais ça:
Une fois ton fichier ouvert dans Avidemux tu bouges le curseur en bas jusqu'à arriver sur l'endroit que tu veux.
Ensuite Edition -> Marqueur A.
Puis tu bouges le curseur jusqu'à la fin de la séquence.
Ensuite Edition -> Marqueur B
Enfin Edition -> Supprimer

Et voilà !

Il faut les préparer à l'avance (donc choisir des sujets non liés à l'actualité) et ensuite, hop, on les poste une par une chaque jour.
Mais sinon je confirme que faire des dépêches c'est chronophage.