Pas besoin d'être ironique, je n'ai jamais dit que la journaliste cherchait à nous cacher le fait que le rapport avait été commandé par la MPA. Il suffit de lire les premières lignes de son article pour voir qu'elle cite ce fait.
Ce qui me chagrine c'est qu'elle n'en tire aucune conclusion quand à l'impartialité de l'étude. A tous le moins, sans même envisager qu'elle puisse contre-enquêter puisque ce genre de journalisme d'investigation semble être en voie de disparition, elle aurait pu ajouter un paragraphe d'avertissement au lecteur et dire que le rapport n'était pas scientifiquement neutre et essayer de croiser avec d'autres sources.
Là c'est vraiment : "Je reçois dans ma boite mail une news release de la MPA puisque je suis journaliste accréditée auprès des studios, hop je traduis 2 ou 3 phrases du summary pour décideur pressé (je vais quand même pas me faire chier à aller lire le rapport lui-même), hop j'enrobe ça avec quelques phrases et voilà j'expédie tout ça à la rédaction à Paris".
Du travail d'assistante de com' et pas du travail de journaliste.
Un certain nombre de personnes (dont moi) ont demandé pourquoi il était nécessaire de réinventer la roue et est-ce qu'il ne serait pas mieux d'importer directement l'outil d'OpenBSD (pf) qui semble apprécié de tous.
La réponse :
"To clarify: I certainly did consider the way pf does things and there are quite a few things I like better than in iptables, starting with having a language specifically designed for filtering rules, compared to the quite primitive shell command invocation mainly used with iptables.
But porting the kernel side doesn't make sense at all. The code structure doesn't match how things are done in the Linux kernel, the API doesn't match what we want, its tightly coupled to a different NAT and state tracking system and even basic things like rule evaluation order are different from what iptables does. There's no way to transform it into something that can be backwards compatible with iptables/ip6tables/arptables/ebtables without basically rewriting it."
>>> Les décisions de sécurité ont été faite par la distribution. Si on ne les aime pas, on change de distribution ou on se documente pour savoir comment les adapter.
Ce sera la même chose quand TOMOYO sera dans le noyau.
Les distributions (qui savent prendre des décisions de sécurité) auront un choix plus large de module de sécurité pour répondre à leurs besoins particulier.
Les utilisateurs de base, qui ne savent pas vraiment faire un choix éclairé en matière de sécurité, utiliseront ce qui aura été configuré par leur distro.
Les power users, qui eux savent faire des choix éclairés, pourront changer de module si ils ont une préférence pour l'un ou l'autre.
Je ne vois pas de qu'il y a de néfaste là dedans.
>>> > les utilisateurs de Linux pourront donc comparer les approches et choisir le module qui leur conviendra le mieux.
C'est "tragique" de lire ça. Pourquoi ne pas donner le choix "compte utilisateur root + anti-virus (à la Windows)" comme choix à l'utilisateur...
Je n'ai pas compris ta remarque. C'est le fait d'avoir le choix qui te dérange ?
Est-ce que tu a cliqué sur les hyperliens que j'ai mis derrière les expressions "avantages distincts" et "comparer les approches" et qui expliquent l'utilité des divers modules en les comparant ?
Merci pour tes précisions.
D'après http://lwn.net/Articles/244295/ je crois que la situation de LRO n'étais pas si rose que ça.
Le lien explique que LRO a été introduit par le pilote Neterion a l'époque du 2.6.17 et que quand les devs du pilote Myri-10G ont voulu introduire LRO dans leur pilote à eux cela a été rejeté car évidemment personne ne souhaitait avoir une implémentation différente pour chaque pilote.
La solution passait par un code LRO générique qui serait réutilisé par tous les pilotes.
L'ennui c'est que le pilote NetXen a été intégré par erreur avec son implémentation LRO spécifique dans le noyau 2.6.20 et donc tout le monde a gueulé.
La nouveauté du noyau 2.6.29 c'est l'entrée de cette implémentation complètement générique (qui a été nommée, tu a raison, GRO pour Generic Receive Offload).
Maintenant je me suis basé sur LWN pour écrire ça mais il a peut-être des erreurs dans l'article ou alors j'ai mal compris.
Je poste ce commentaire pour avoir un peu un retour de la part des lecteurs des dépêches sur le noyau.
Je m'interroge pour savoir si il y aurait des trucs à changer et je vous demande votre avis sur ces points :
1) Est-ce que la première partie qui récapitule les diverses release candidates en traduisant une partie des mails de Linus est utile ou pas ? Qu'est-ce qu'il faudrait changer selon vous (fond, forme) ?
2) La seconde partie qui détaille les "grosses" nouveautés doit-elle être ullifiée ou pas ? Est-elle trop longue, pas assez longue, trop technique, pas assez technique, etc ?
3) Il y a beaucoup de d'hyperliens dans ces dépêches sur le noyau (une centaine dans celle-ci). Est-ce que vous cliquez sur ces liens ou pas ? Si oui sur combien en moyenne ? Est-ce qu'il y en a trop ou non ?
4) Le paragraphe sur le bilan statistique du cycle de développement avec les principaux contributeurs est-il utile ou pas ? Est-ce que ça vous intéresse ?
5) Est-ce que vous avez des idées pour améliorer ces dépêches sur le noyau ?
PS-1 : Ne vous sentez pas obligé de répondre à toutes les questions. Je n'ai fait cette liste que pour donner à réfléchir mais vous pouvez parfaitement faire une réponse globale ou même faire une suggestion sans répondre aux questions.
PS-2 : Évidemment je ne promets rien en ce qui concerne l'implémentation de vos suggestions et je me réserve le droit de ne rien changer du tout ;-)
Pareil. Bravo à l'auteur du journal qui a vraiment fait son devoir de citoyen et qui a donné de son temps.
Aucune chance pour qu'on sache le nom de ce député ?
Moi je ne vois pas ce qu'il y a de choquant dans ce film.
Je fais la même chose quand il y a quelqu'un chez moi qui ose approcher ses doigts sales de la reliure d'un de mes chers livres.
Avant d'avoir l'immense honneur de le frôler il doit d'abord signer avec son sang et me promettre une servitude éternelle en cas de dégradation.
Quand à lui prêter mon livre n'en parlons même pas....
Bien entendu cette entreprise à le droit de faire ce qu'elle fait.
Ce n'est pas une question d'avoir le droit ou pas. C'est juste qu'elle impose une restriction arbitraire (l'interdiction de copie) sur un bien numérique qui peut pourtant se copier facilement à coût nul.
La base du numérique est donc bien, selon moi, le pouvoir de copie/modifier et cette possibilité technique naturelle est restreinte par certaines licences.
>>> Une licence libre te donne des libertés *supplémentaires*
Je ne considère pas qu'une licence libre me donne des libertés supplémentaires. Je pense qu'au contraire, dans l'univers du numérique qui est très spécifique, le droit à la copie/modification est la base. Ce sont les licences propriétaires qui dérogent à cette base en choisissant de m'enlever des droits.
>>> Je ne vois pas en quoi ça "prive" l'utilisateur de quelquechose
Le principe même du numérique c'est la possibilité technique de faire des copies parfaites à coût nul.
Quand un logiciel spécifie dans sa licence qu'il est interdit de le copier alors il me prive bien d'une possibilité qui, autrement, serait toute naturelle.
Je ne comprends pas bien ton reproche. Qu'est-ce que tu veux dire par "pas la possibilité d'afficher les différents genres de la bibliothèque" ?
Moi habituellement je n'affiche que les fenêtres pour Artiste, Album et Titre mais si tu va dans les préférences tu peux aussi afficher le genre (pourvu que les tags de genre soient renseignés dans ta bibliothèque bien sûr).
Je dis "bonne" car pour une fois on entend des critiques et pas seulement un résumé des features.
Par exemple pour ton "la barre d'adresse dans epiphany qui ne met pas 2 plombes pour afficher les adresses lorsqu'on tape le début de l'adresse ou un mot clé, c'est... bof ?" on note un giga défaut de l'implémentation choisie par Epiphany :
"One problem that I noticed during my tests is that it displays iframe URLs in the completion list. This totally clutters up the results with irrelevant ad URLS rather than desirable destinations."
Effectivement quand on voit le screenshot on se rend compte que la fonction est quasi inutilisable.
>>> La société doit favoriser de tout son pouvoir les progrès de la raison publique, et mettre l’instruction à la portée de tous les citoyens
Si tu vois là un appel au droit universel de télécharger le dernier album de Johnny alors nous n'avons pas la même définition de l'instruction et de la raison.
>>> il y a un peu plus de 60 ans, sauver des gens de la déportation t'aurait-il paru aussi indéfendable que de faire du marché noir ?
"Nous parlerons contre les lois insensées jusqu'à ce qu'on les réforme, et, en attendant, nous nous y soumettrons. Celui qui, de son autorité privée, enfreint une loi mauvaise, autorise tout autre à enfreindre les bonnes".
[^] # Re: Trahison
Posté par patrick_g (site web personnel) . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 6.
Ce qui me chagrine c'est qu'elle n'en tire aucune conclusion quand à l'impartialité de l'étude. A tous le moins, sans même envisager qu'elle puisse contre-enquêter puisque ce genre de journalisme d'investigation semble être en voie de disparition, elle aurait pu ajouter un paragraphe d'avertissement au lecteur et dire que le rapport n'était pas scientifiquement neutre et essayer de croiser avec d'autres sources.
Là c'est vraiment : "Je reçois dans ma boite mail une news release de la MPA puisque je suis journaliste accréditée auprès des studios, hop je traduis 2 ou 3 phrases du summary pour décideur pressé (je vais quand même pas me faire chier à aller lire le rapport lui-même), hop j'enrobe ça avec quelques phrases et voilà j'expédie tout ça à la rédaction à Paris".
Du travail d'assistante de com' et pas du travail de journaliste.
[^] # Re: Verité
Posté par patrick_g (site web personnel) . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 8.
Et Olivennes en ministre des finances c'est beau aussi non ?
[^] # Re: Source de financement du rapport
Posté par patrick_g (site web personnel) . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 10.
[^] # Re: payer
Posté par patrick_g (site web personnel) . En réponse au journal La riposte graduée déjà obsolète. Évalué à 4.
# Linux Weekly News
Posté par patrick_g (site web personnel) . En réponse au journal NFtables, successeur d'Iptables. Évalué à 9.
Un certain nombre de personnes (dont moi) ont demandé pourquoi il était nécessaire de réinventer la roue et est-ce qu'il ne serait pas mieux d'importer directement l'outil d'OpenBSD (pf) qui semble apprécié de tous.
La réponse :
"To clarify: I certainly did consider the way pf does things and there are quite a few things I like better than in iptables, starting with having a language specifically designed for filtering rules, compared to the quite primitive shell command invocation mainly used with iptables.
But porting the kernel side doesn't make sense at all. The code structure doesn't match how things are done in the Linux kernel, the API doesn't match what we want, its tightly coupled to a different NAT and state tracking system and even basic things like rule evaluation order are different from what iptables does. There's no way to transform it into something that can be backwards compatible with iptables/ip6tables/arptables/ebtables without basically rewriting it."
[^] # Re: Re:
Posté par patrick_g (site web personnel) . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 6.
Ce sera la même chose quand TOMOYO sera dans le noyau.
Les distributions (qui savent prendre des décisions de sécurité) auront un choix plus large de module de sécurité pour répondre à leurs besoins particulier.
Les utilisateurs de base, qui ne savent pas vraiment faire un choix éclairé en matière de sécurité, utiliseront ce qui aura été configuré par leur distro.
Les power users, qui eux savent faire des choix éclairés, pourront changer de module si ils ont une préférence pour l'un ou l'autre.
Je ne vois pas de qu'il y a de néfaste là dedans.
[^] # Re: Re:
Posté par patrick_g (site web personnel) . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 3.
Merci.
[^] # Re: Re:
Posté par patrick_g (site web personnel) . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 3.
C'est "tragique" de lire ça. Pourquoi ne pas donner le choix "compte utilisateur root + anti-virus (à la Windows)" comme choix à l'utilisateur...
Je n'ai pas compris ta remarque. C'est le fait d'avoir le choix qui te dérange ?
Est-ce que tu a cliqué sur les hyperliens que j'ai mis derrière les expressions "avantages distincts" et "comparer les approches" et qui expliquent l'utilité des divers modules en les comparant ?
[^] # Re: LRO n'est pas nouveau...
Posté par patrick_g (site web personnel) . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 10.
Arf j'avais même pas réalisé.
Bon ben j'ai l'air couillon maintenant ;-)
[^] # Re: LRO n'est pas nouveau...
Posté par patrick_g (site web personnel) . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 3.
D'après http://lwn.net/Articles/244295/ je crois que la situation de LRO n'étais pas si rose que ça.
Le lien explique que LRO a été introduit par le pilote Neterion a l'époque du 2.6.17 et que quand les devs du pilote Myri-10G ont voulu introduire LRO dans leur pilote à eux cela a été rejeté car évidemment personne ne souhaitait avoir une implémentation différente pour chaque pilote.
La solution passait par un code LRO générique qui serait réutilisé par tous les pilotes.
L'ennui c'est que le pilote NetXen a été intégré par erreur avec son implémentation LRO spécifique dans le noyau 2.6.20 et donc tout le monde a gueulé.
La nouveauté du noyau 2.6.29 c'est l'entrée de cette implémentation complètement générique (qui a été nommée, tu a raison, GRO pour Generic Receive Offload).
Maintenant je me suis basé sur LWN pour écrire ça mais il a peut-être des erreurs dans l'article ou alors j'ai mal compris.
[^] # Re: Petites questions
Posté par patrick_g (site web personnel) . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 4.
Je sais pas vraiment car ça s'étale sur deux bons mois...mais ça prend du temps !
# Petites questions
Posté par patrick_g (site web personnel) . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 10.
Je poste ce commentaire pour avoir un peu un retour de la part des lecteurs des dépêches sur le noyau.
Je m'interroge pour savoir si il y aurait des trucs à changer et je vous demande votre avis sur ces points :
1) Est-ce que la première partie qui récapitule les diverses release candidates en traduisant une partie des mails de Linus est utile ou pas ? Qu'est-ce qu'il faudrait changer selon vous (fond, forme) ?
2) La seconde partie qui détaille les "grosses" nouveautés doit-elle être ullifiée ou pas ? Est-elle trop longue, pas assez longue, trop technique, pas assez technique, etc ?
3) Il y a beaucoup de d'hyperliens dans ces dépêches sur le noyau (une centaine dans celle-ci). Est-ce que vous cliquez sur ces liens ou pas ? Si oui sur combien en moyenne ? Est-ce qu'il y en a trop ou non ?
4) Le paragraphe sur le bilan statistique du cycle de développement avec les principaux contributeurs est-il utile ou pas ? Est-ce que ça vous intéresse ?
5) Est-ce que vous avez des idées pour améliorer ces dépêches sur le noyau ?
PS-1 : Ne vous sentez pas obligé de répondre à toutes les questions. Je n'ai fait cette liste que pour donner à réfléchir mais vous pouvez parfaitement faire une réponse globale ou même faire une suggestion sans répondre aux questions.
PS-2 : Évidemment je ne promets rien en ce qui concerne l'implémentation de vos suggestions et je me réserve le droit de ne rien changer du tout ;-)
[^] # Re: Je n'aurais qu'un mot
Posté par patrick_g (site web personnel) . En réponse au journal Rencontre avec son député, c'est *utile* ET indolore.. Évalué à 5.
Aucune chance pour qu'on sache le nom de ce député ?
# Ben quoi ?
Posté par patrick_g (site web personnel) . En réponse au journal [vidéo pas sérieuse] EULA for friends. Évalué à 8.
Je fais la même chose quand il y a quelqu'un chez moi qui ose approcher ses doigts sales de la reliure d'un de mes chers livres.
Avant d'avoir l'immense honneur de le frôler il doit d'abord signer avec son sang et me promettre une servitude éternelle en cas de dégradation.
Quand à lui prêter mon livre n'en parlons même pas....
[^] # Re: Logiciels "privateurs"
Posté par patrick_g (site web personnel) . En réponse au journal RMS et le piège du Javascript. Évalué à 2.
Ce n'est pas une question d'avoir le droit ou pas. C'est juste qu'elle impose une restriction arbitraire (l'interdiction de copie) sur un bien numérique qui peut pourtant se copier facilement à coût nul.
La base du numérique est donc bien, selon moi, le pouvoir de copie/modifier et cette possibilité technique naturelle est restreinte par certaines licences.
[^] # Re: Logiciels "privateurs"
Posté par patrick_g (site web personnel) . En réponse au journal RMS et le piège du Javascript. Évalué à 4.
Je ne considère pas qu'une licence libre me donne des libertés supplémentaires. Je pense qu'au contraire, dans l'univers du numérique qui est très spécifique, le droit à la copie/modification est la base. Ce sont les licences propriétaires qui dérogent à cette base en choisissant de m'enlever des droits.
Ne voulant pas me répéter je te colle le lien vers un argumentaire que j'avais écrit à l'époque :
https://linuxfr.org//comments/932032.html#932032
[^] # Re: Logiciels "privateurs"
Posté par patrick_g (site web personnel) . En réponse au journal RMS et le piège du Javascript. Évalué à 9.
Le principe même du numérique c'est la possibilité technique de faire des copies parfaites à coût nul.
Quand un logiciel spécifie dans sa licence qu'il est interdit de le copier alors il me prive bien d'une possibilité qui, autrement, serait toute naturelle.
[^] # Re: Les autres : Amarok, songbird, Quodlibet etc...
Posté par patrick_g (site web personnel) . En réponse à la dépêche Rhythmbox 0.12 "Flood Victim" est sorti. Évalué à 6.
Ben le souci quand on est sous Gnome c'est l'intégration. Y'a pas photo entre Songbird et Rhythmbox à ce niveau.
[^] # Re: Mon opinion, par rapport à mpd
Posté par patrick_g (site web personnel) . En réponse à la dépêche Rhythmbox 0.12 "Flood Victim" est sorti. Évalué à 3.
Comme dit plus haut il suffit d'un alias basique (ry ?) et ça roule.
>>> rhythmbox arrivait souvent à me saccader la musique tant il à besoin de ressources pour lire un fichier son
Jamais rencontré ce problème. Tu montes à combien de % de charge CPU ?
>>> Cela étant, mpd ne fait pas de mise à jour en continue de la médiathèque
C'est aussi désactivable dans Rhythmbox pour ceux, comme moi, qui préfèrent updater à la main la base quand ils ajoutent des musiques.
[^] # Re: Malade !?
Posté par patrick_g (site web personnel) . En réponse à la dépêche Rhythmbox 0.12 "Flood Victim" est sorti. Évalué à 10.
[^] # Re: Dommage...
Posté par patrick_g (site web personnel) . En réponse à la dépêche Rhythmbox 0.12 "Flood Victim" est sorti. Évalué à 3.
Moi habituellement je n'affiche que les fenêtres pour Artiste, Album et Titre mais si tu va dans les préférences tu peux aussi afficher le genre (pourvu que les tags de genre soient renseignés dans ta bibliothèque bien sûr).
Regarde la capture d'écran que je viens de faire après avoir modifié mes préférences pour afficher le genre : http://farm4.static.flickr.com/3067/3376415609_09999a2eda_o.(...)
Ou alors j'ai mal compris ?
[^] # Re: ah oui
Posté par patrick_g (site web personnel) . En réponse au journal Pigalle, DSLZ, téléchargement, toussa. Évalué à 2.
[^] # Re: Mouais bof
Posté par patrick_g (site web personnel) . En réponse à la dépêche GNOME 2.26 est disponible. Évalué à 1.
http://arstechnica.com/open-source/reviews/2009/03/hands-on-(...)
Je dis "bonne" car pour une fois on entend des critiques et pas seulement un résumé des features.
Par exemple pour ton "la barre d'adresse dans epiphany qui ne met pas 2 plombes pour afficher les adresses lorsqu'on tape le début de l'adresse ou un mot clé, c'est... bof ?" on note un giga défaut de l'implémentation choisie par Epiphany :
"One problem that I noticed during my tests is that it displays iframe URLs in the completion list. This totally clutters up the results with irrelevant ad URLS rather than desirable destinations."
Effectivement quand on voit le screenshot on se rend compte que la fonction est quasi inutilisable.
[^] # Re: cette loi va passer parce que
Posté par patrick_g (site web personnel) . En réponse au journal Pourquoi l'HADOPI va passer.... Évalué à 2.
Si tu vois là un appel au droit universel de télécharger le dernier album de Johnny alors nous n'avons pas la même définition de l'instruction et de la raison.
>>> il y a un peu plus de 60 ans, sauver des gens de la déportation t'aurait-il paru aussi indéfendable que de faire du marché noir ?
Bravo pour le point Godwin.
[^] # Re: cette loi va passer parce que
Posté par patrick_g (site web personnel) . En réponse au journal Pourquoi l'HADOPI va passer.... Évalué à 4.
– Diderot