Ouais enfin le fait que les pilotes soient en mainline ça permet aussi de changer les API internes afin de corriger les erreurs et de mieux maintenir sur le long terme.
Linux ne se traine pas des boulets de compatibilité comme Windows.
Donc moi je crois que "le projet dans son ensemble" s'en sort mieux que Windows...c'est pas Greg KH qui disait que Linux est l'OS le plus compatible de tous les temps ?
En 2006 Linus Torvalds a fait plusieurs longs posts argumentés sur le site Realworldtech pour donner son avis sur les micro-noyaux (on sait que c'était déjà le sujet du fameux débat avec Tanenbaum en 1992).
Je pense qu'il est interessant d'en faire une traduction partielle afin de comprendre pourquoi il n'aime pas cette architecture. J'ai traduit les passages qui me semblent importants (j'ai charcuté donc) mais vous êtes invités à aller lire les posts complets pour vous faire une vraie idée de ses arguments.
Résumé du début du post : Il explique qu'il se fiche des questions d'implémentations et de vocabulaire et que la seule chose importante, la différence réelle et cruciale entre les noyaux monolithiques et les micro-noyaux c'est l'adressage mémoire. Il est séparé pour les micro-noyaux alors qu'il est commun pour les noyaux monolithiques. La seule vraie barrière dans les noyaux classiques c'est celle qui existe entre les applications utilisateurs et le noyau. Les micro-noyaux eux, mettent des barrières partout
Traduction du reste :
"Maintenant le vrai problème avec cette séparation n'est pas la question des performances (qui existe pourtant) mais plutôt le problème de la complexité. Il est risible de voir les partisans des micro-noyaux proclamer que leurs systèmes sont "plus simples" que les noyaux traditionnels. Ce n'est pas le cas. Ils sont bien plus compliqués du fait de cette barrière qui existe entre les structures de données.
Le résultat fondamental de cette séparation de l'adressage mémoire est que vous ne pouvez pas partager les structures de données. Cela veut dire que vous ne pouvez pas partager les verrous, cela veut dire que vous devez copier toutes les données partagés et cela implique que vous avez énormément de mal à gérer la cohérence.
Fondamentalement tous vos algorithmes deviennent des algorithmes distribués.
Et celui qui vous dit que les algorithmes distribués sont "plus simples" à la tête tellement rempli de m*rde que ce n'est même plus drôle.
Les micro-noyaux sont bien plus difficiles à écrire et à maintenir exactement pour cette raison. Vous pouvez faire les choses simples assez facilement - en particulier quand vous n'avez à passer l'information que dans un sens - mais tout le reste est incomparablement plus difficile parce qu'il n'y a pas de partage d'état (par design). Et en l'absence de ce partage vous avez une sacré quantité de problèmes pour prendre une décision qui concerne plus d'une entité dans le système.
Et je ne suis pas juste en train de blablater. C'est un fait. Un fait qui a été montré en pratique encore et encore, et pas seulement dans le domaine des noyaux. Mais cela s'est vérifié aussi pour les noyaux et pas qu'une seule fois. Tout l'argument "les micro-noyaux sont plus simples" c'est juste de la connerie et le fait que ce soit de la connerie se voit quand on compare la vitesse de développement d'un micro-noyau et d'un noyau traditionnel. Le noyau traditionnel gagne. Et avec une marge énorme en plus.
Tout l'argument disant que les micro-noyaux sont "plus sécurisés" ou "plus stables" est aussi totalement grotesque. Le fait que chaque pièce individuelle soit simple et sécurisée ne fait pas que leur aggrégation soit simple et sécurisée. Et l'argument que vous pouvez "simplement relancer" un serveur défaillant sans emporter tout le système est également fautif.
Quiconque a déjà fait de la programmation distribuée devrait savoir maintenant que quand un noeud se vautre le reste se vautre aussi. Ce n'est pas toujours vrai (mais il n'est pas toujours vrai aussi qu'un crash de pilote fasse tomber à chaque fois un noyau monolithique), mais c'est souvent le cas s'il y a une dépendance mutuelle ou un problème de cohérence.
Et dans le domaine des systèmes d'exploitations il y sacrément peu de trucs qui n'ont pas de problème de cohérence. Si il n'y avait pas de problème de cohérence sela ne serait pas dans le noyau de tout façon !".
Le second post ou il réponds à quelqu'un lui disant que certaines personnes pensent que les avantages des micro-noyaux compensent les inconvénients :
"Et bien jusqu'à présent ces personnes n'ont même pas été capables de nommer ces avantages hypothétiques.
J'ai vu des affirmations grotesques à propos de la "facilité" (en fait c'était l'argument des années 80 et 90) et j'ai même été convaincu à une époque. Depuis j'ai appris ce qui est facile et ce qui est difficile - et j'ai vu les gens échouer avec leurs micro-noyaux encore et encore - Il est devenu évident pour moi que l'argument de la simplicité était faux.
L'an dernier le dernier argument magique c'était la "sécurité". C'est tout aussi grotesque que la "facilité et pour les mêmes raisons. Les bugs de sécurité sont souvent dans les interactions de deux sous-systèmes et plus difficile c'est à écrire et maintenir, plus difficile c'est à sécuriser.
Je suis certain que dans dix ans il y aura d'autre arguments. Il y a toujours une excuse.
Au final (et c'est je pense décisif) le vrai argument pour les micro-noyaux n'a rien à voir avec la vitesse, la facilité, la sécurité ou le reste.
La vraie raison pour laquelle les gens font des micro-noyaux (et vont probablement continuer de le faire en inventant de nouvelles bonnes raisons prouvant que c'est la meilleure solution) c'est que le concept lui-même est si séduisant. J'ai été séduit moi aussi !
Toute cette histoire de "petits modules indépendants" sonne vraiment comme la manne tombée du ciel quand vous êtes confronté à la tâche gigantesque de créer un OS et que vous réalisez à quel point c'est une tâche énorme.
Cette idée des "micro-noyaux qui sont merveilleux" vient de ce souhait désespéré que le monde devrait être plus simple qu'il ne l'est réellement. C'est pourquoi les micro-noyaux sont si populaires dans les cercles académiques ou personne ne peut se permettre de mettre un gros team de développement et ou il est donc absolument nécessaire que le problème soit simple.
La réalité n'a rien à voir avec les micro-noyaux. C'est l'inverse en fait. Le vrai but des micro-noyaux c'est d'échapper à la réalité du fait que le design et l'implémentation d'OS complet est difficile et que c'est beaucoup de travail".
Mais quel est le rapport entre un institut d'astrophysique et la MPAA ?
L'institut d'astrophysique n'a aucun intérêt à forger l'information de toute pièce et l'information elle-même est sans enjeu économique fort.
Est-ce qu'à ton avis c'est le cas aussi pour la MPAA ? Nom d'un chien c'est de la Motion Picture Association of America qu'on parle !
C'est l'association qui a le plus intérêt au monde a réduire la contrefaçon de films !
Est-ce que tu est allé sur la page d'accueil de leur site ? Je ne te parle pas des tréfonds de leur arborescence hein, juste de la page d'accueil : http://www.mpaa.org/
On y trouve :
Movies thieves :
- Who are they?
- Who do they hurt?
- Get involved in our fight to stop movie thieves!
Il y a un compteur de saisie des DVD contrefaits :
Catching Movie thieves :
Each week, law enforcement around the world catch movie thieves red handed.
Since last year, authorities have seized over : 81 millions conterfeit DVD
Il y a une campagne d'éducation contre le "piratage" :
MPAA Education OUtreach :
Education is key in the fight against copyright theft. Many people don’t know what copyright theft is or about the serious consequences it holds. MPAA is committed to helping raise awareness to this important issue and is taking our copyright education campaign to schools and universities around the world.
Et tout ça juste sur la page d'accueil ! Il faudrait être aveugle pour ne pas le voir....
Alors maintenant dis-moi quelle est à priori la valeur d'un rapport payé par la MPAA pour analyser les connexions entre le terrorisme et la contrefaçon de DVD ?
Moi je dirai à peu près autant qu'un rapport de l'armée israélienne qui dirait que ses soldats se sont conduits de façon exemplairement morale à Gaza ou qu'un rapport du Hamas qui dirait que les soldats israéliens sont les pires barbares depuis Attila. Ces deux entités sont parties prenantes et donc il faut être ultra critique quand elles sortent une déclaration.
C'est la même chose pour ce rapport c'est tout.
>>> Un journaliste fait un boulot correct (et donne toutes les sources contrairement à dlfp...), mais comme ce qu'elle dit pourrait ne pas plaire, on l'insulte.
Hem...c'est moi qui ai donné le lien vers le rapport et pas la journaliste justement !
>>> patrick_g a-t-il maintenant relativisé ou sa crise de connerie ne lui est pas encore passée ?
Ah on retrouve le IsNotGood des grandes heures ! Sa politesse légendaire et sa courtoisie inimitable.
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.
[^] # Re: L'avis de Linus
Posté par patrick_g (site web personnel) . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 5.
Linux ne se traine pas des boulets de compatibilité comme Windows.
Donc moi je crois que "le projet dans son ensemble" s'en sort mieux que Windows...c'est pas Greg KH qui disait que Linux est l'OS le plus compatible de tous les temps ?
# L'avis de Linus
Posté par patrick_g (site web personnel) . En réponse à la dépêche MINIX 3 - Google Summer of Code. Évalué à 10.
Je pense qu'il est interessant d'en faire une traduction partielle afin de comprendre pourquoi il n'aime pas cette architecture. J'ai traduit les passages qui me semblent importants (j'ai charcuté donc) mais vous êtes invités à aller lire les posts complets pour vous faire une vraie idée de ses arguments.
Résumé du début du post : Il explique qu'il se fiche des questions d'implémentations et de vocabulaire et que la seule chose importante, la différence réelle et cruciale entre les noyaux monolithiques et les micro-noyaux c'est l'adressage mémoire. Il est séparé pour les micro-noyaux alors qu'il est commun pour les noyaux monolithiques. La seule vraie barrière dans les noyaux classiques c'est celle qui existe entre les applications utilisateurs et le noyau. Les micro-noyaux eux, mettent des barrières partout
Traduction du reste :
"Maintenant le vrai problème avec cette séparation n'est pas la question des performances (qui existe pourtant) mais plutôt le problème de la complexité. Il est risible de voir les partisans des micro-noyaux proclamer que leurs systèmes sont "plus simples" que les noyaux traditionnels. Ce n'est pas le cas. Ils sont bien plus compliqués du fait de cette barrière qui existe entre les structures de données.
Le résultat fondamental de cette séparation de l'adressage mémoire est que vous ne pouvez pas partager les structures de données. Cela veut dire que vous ne pouvez pas partager les verrous, cela veut dire que vous devez copier toutes les données partagés et cela implique que vous avez énormément de mal à gérer la cohérence.
Fondamentalement tous vos algorithmes deviennent des algorithmes distribués.
Et celui qui vous dit que les algorithmes distribués sont "plus simples" à la tête tellement rempli de m*rde que ce n'est même plus drôle.
Les micro-noyaux sont bien plus difficiles à écrire et à maintenir exactement pour cette raison. Vous pouvez faire les choses simples assez facilement - en particulier quand vous n'avez à passer l'information que dans un sens - mais tout le reste est incomparablement plus difficile parce qu'il n'y a pas de partage d'état (par design). Et en l'absence de ce partage vous avez une sacré quantité de problèmes pour prendre une décision qui concerne plus d'une entité dans le système.
Et je ne suis pas juste en train de blablater. C'est un fait. Un fait qui a été montré en pratique encore et encore, et pas seulement dans le domaine des noyaux. Mais cela s'est vérifié aussi pour les noyaux et pas qu'une seule fois. Tout l'argument "les micro-noyaux sont plus simples" c'est juste de la connerie et le fait que ce soit de la connerie se voit quand on compare la vitesse de développement d'un micro-noyau et d'un noyau traditionnel. Le noyau traditionnel gagne. Et avec une marge énorme en plus.
Tout l'argument disant que les micro-noyaux sont "plus sécurisés" ou "plus stables" est aussi totalement grotesque. Le fait que chaque pièce individuelle soit simple et sécurisée ne fait pas que leur aggrégation soit simple et sécurisée. Et l'argument que vous pouvez "simplement relancer" un serveur défaillant sans emporter tout le système est également fautif.
Quiconque a déjà fait de la programmation distribuée devrait savoir maintenant que quand un noeud se vautre le reste se vautre aussi. Ce n'est pas toujours vrai (mais il n'est pas toujours vrai aussi qu'un crash de pilote fasse tomber à chaque fois un noyau monolithique), mais c'est souvent le cas s'il y a une dépendance mutuelle ou un problème de cohérence.
Et dans le domaine des systèmes d'exploitations il y sacrément peu de trucs qui n'ont pas de problème de cohérence. Si il n'y avait pas de problème de cohérence sela ne serait pas dans le noyau de tout façon !".
Le second post ou il réponds à quelqu'un lui disant que certaines personnes pensent que les avantages des micro-noyaux compensent les inconvénients :
"Et bien jusqu'à présent ces personnes n'ont même pas été capables de nommer ces avantages hypothétiques.
J'ai vu des affirmations grotesques à propos de la "facilité" (en fait c'était l'argument des années 80 et 90) et j'ai même été convaincu à une époque. Depuis j'ai appris ce qui est facile et ce qui est difficile - et j'ai vu les gens échouer avec leurs micro-noyaux encore et encore - Il est devenu évident pour moi que l'argument de la simplicité était faux.
L'an dernier le dernier argument magique c'était la "sécurité". C'est tout aussi grotesque que la "facilité et pour les mêmes raisons. Les bugs de sécurité sont souvent dans les interactions de deux sous-systèmes et plus difficile c'est à écrire et maintenir, plus difficile c'est à sécuriser.
Je suis certain que dans dix ans il y aura d'autre arguments. Il y a toujours une excuse.
Au final (et c'est je pense décisif) le vrai argument pour les micro-noyaux n'a rien à voir avec la vitesse, la facilité, la sécurité ou le reste.
La vraie raison pour laquelle les gens font des micro-noyaux (et vont probablement continuer de le faire en inventant de nouvelles bonnes raisons prouvant que c'est la meilleure solution) c'est que le concept lui-même est si séduisant. J'ai été séduit moi aussi !
Toute cette histoire de "petits modules indépendants" sonne vraiment comme la manne tombée du ciel quand vous êtes confronté à la tâche gigantesque de créer un OS et que vous réalisez à quel point c'est une tâche énorme.
Cette idée des "micro-noyaux qui sont merveilleux" vient de ce souhait désespéré que le monde devrait être plus simple qu'il ne l'est réellement. C'est pourquoi les micro-noyaux sont si populaires dans les cercles académiques ou personne ne peut se permettre de mettre un gros team de développement et ou il est donc absolument nécessaire que le problème soit simple.
La réalité n'a rien à voir avec les micro-noyaux. C'est l'inverse en fait. Le vrai but des micro-noyaux c'est d'échapper à la réalité du fait que le design et l'implémentation d'OS complet est difficile et que c'est beaucoup de travail".
Le premier post est ici : http://www.realworldtech.com/forums/index.cfm?action=detail&(...)
Le second là : http://www.realworldtech.com/forums/index.cfm?action=detail&(...)
Et il y en a d'autres dans le thread....de la lecture pour ce vendredi pluvieux !
[^] # Re: Trahison
Posté par patrick_g (site web personnel) . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 5.
L'institut d'astrophysique n'a aucun intérêt à forger l'information de toute pièce et l'information elle-même est sans enjeu économique fort.
Est-ce qu'à ton avis c'est le cas aussi pour la MPAA ? Nom d'un chien c'est de la Motion Picture Association of America qu'on parle !
C'est l'association qui a le plus intérêt au monde a réduire la contrefaçon de films !
Est-ce que tu est allé sur la page d'accueil de leur site ? Je ne te parle pas des tréfonds de leur arborescence hein, juste de la page d'accueil : http://www.mpaa.org/
On y trouve :
Movies thieves :
- Who are they?
- Who do they hurt?
- Get involved in our fight to stop movie thieves!
Il y a un compteur de saisie des DVD contrefaits :
Catching Movie thieves :
Each week, law enforcement around the world catch movie thieves red handed.
Since last year, authorities have seized over : 81 millions conterfeit DVD
Il y a une campagne d'éducation contre le "piratage" :
MPAA Education OUtreach :
Education is key in the fight against copyright theft. Many people don’t know what copyright theft is or about the serious consequences it holds. MPAA is committed to helping raise awareness to this important issue and is taking our copyright education campaign to schools and universities around the world.
Et tout ça juste sur la page d'accueil ! Il faudrait être aveugle pour ne pas le voir....
Alors maintenant dis-moi quelle est à priori la valeur d'un rapport payé par la MPAA pour analyser les connexions entre le terrorisme et la contrefaçon de DVD ?
Moi je dirai à peu près autant qu'un rapport de l'armée israélienne qui dirait que ses soldats se sont conduits de façon exemplairement morale à Gaza ou qu'un rapport du Hamas qui dirait que les soldats israéliens sont les pires barbares depuis Attila. Ces deux entités sont parties prenantes et donc il faut être ultra critique quand elles sortent une déclaration.
C'est la même chose pour ce rapport c'est tout.
[^] # Re: joli sophisme...
Posté par patrick_g (site web personnel) . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 8.
Hem...c'est moi qui ai donné le lien vers le rapport et pas la journaliste justement !
>>> patrick_g a-t-il maintenant relativisé ou sa crise de connerie ne lui est pas encore passée ?
Ah on retrouve le IsNotGood des grandes heures ! Sa politesse légendaire et sa courtoisie inimitable.
[^] # Re: Trahison
Posté par patrick_g (site web personnel) . En réponse au journal Contrefaçon de DVD et terrorisme. Évalué à 3.
[^] # 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.