patrick_g a écrit 6453 commentaires

Corrigé merci.

>>> En plus, le premier commentaire de la dépêche, c'est une critique, et en plus par un modérateur qui aurait pu la faire avant la validation de la dépêche.

Heu...je ne comprends pas trop ce que tu veux dire.
A l'étape de modération nous avons corrigé le titre de la news qui était faux et nous avons ajouté la mention de la licence.
Ensuite mon premier commentaire portait sur le choix du titre du livre et j'ai signalé qu'il y avait un risque de confusion technique. En quoi aurais-je pu faire cette remarque avant la validation de la news ? Ma question porte sur le livre et pas sur la news. Nous pouvons modifier la dépêche mais pas le titre du livre !!
Le titre du livre est ce qu'il est et la publication de la dépêche n'y change rien donc mon interrogation adressée à l'auteur me semble légitime.
En plus il pouvait très bien répondre un truc du style "oui je sais que techniquement ce n'est pas précis mais j'ai tenu compte du grand public et j'ai choisi un titre simple". Cela aurait été une réponse tout à fait valable et pertinente...mais au lieu de ça l'auteur a décidé de se braquer et de s'offusquer des remarques qui sont faites.

>>> Je pense que sur cette dépêche il a manqué une pointe de diplomatie qui aurait pu éviter le déraillage.

A la relecture je ne crois pas que mon commentaire initial soit "très sec, voire même légèrement agaçant" en tout cas ce n'était certainement pas mon intention de poser en donneur de leçons et si l'auteur du livre en a été blessé je le prie d'accepter mes excuses.
Je voulais juste signaler un risque de confusion dans le titre.

>>> certains manquent de courtoisie, et l'exercice demande une grande modestie

Et aussi une peau de rhinocéros pour ne pas se formaliser des critiques.

>>> Le partage de connaissance est bel et bien une des composantes de l'esprit du libre. Il y a partage de connaissance. Ça me suffit, il n'y a pas tromperie sur la marchandise, on va pas pinailler pendant des heures pour une stupide question de formulation.

Je ne sais pas si ce n'est que du pinaillage. La dépêche d'origine, avant modification lors de l'étape de modération, s'intitulait "Linux aux petits oignons : texte intégral libre et gratuit en ligne" et elle ne précisait pas que la licence était BY-NC-ND.
Je pense pas du tout que ce soit par volonté de tromper les gens. A mon avis c'est simplement que l'auteur pensait que mettre son travail en lecture sur le net relevait effectivement de "l'esprit du libre" et qu'il ne savait pas que la BY-NC-ND n'est pas une licence libre.
Malheureusement il a mal pris qu'on lui en fasse la remarque. C'est dommage car son livre est, d'après les deux chapitres que j'ai lu, vraiment bien foutu. Il semble d'ailleurs avoir fait l'unanimité des lecteurs sur ce point et je m'associe à leurs félicitations.

>>> il n'est pas possible d'être rigoureux dans tous les domaines, la moindre discussion deviendrait un enfer aride.

OK mais alors pourquoi ne pas, comme le suggère gbetous plus haut, choisir un titre que tout le monde comprendra du style "Votre distribution Linux aux petits oignons" ?

>>> haque société qui présente son pourcentage d'extrémistes incorrigibles, le monde du libre a sa part de trolls baveux qui sortent de leurs trous à la moindre occasion qui se présente.

Tu a lu mon commentaire au moins ? J'évoque notamment un problème "technique" qui fait qu'en lisant le titre on ne peut pas savoir si le livre ne va parler que du noyau ou si il est plus généraliste et évoque tous les aspects d'une distribution.
En quoi est-ce faire preuve d'un "extrémisme incorrigible" que de dire ça ?

>>> Donc peut être que linux c'est plus compréhensible et finalement moins malhonnête que GNU/linux.

Tu ne répond que sur la polémique lancée par RMS alors que dans mon post je soulignais qu'il existe également une ambigüité technique dans le titre du livre.
Si on te dis que le bouquin "Linux aux petits oignons" est sorti comment est-ce que tu peux savoir si c'est un guide de tuning du noyau ou bien si ça va parler de tous les aspects d'une distribution ?

Désolé, aucune idée.

Hmm..bizarre ça.
Je suis sous Ubuntu Hardy et j'utilise le PPA http://dl.google.com/linux/deb/ pour rapatrier Chrome. C'est peut-être l'empaquetage qui est en cause ?

Je veux pas faire mon grognon mais en lisant le titre on peut croire qu'il s'agit d'un livre pour paramétrer finement son noyau.
Pour éviter cette méprise il aurait suffi de mettre "GNU/Linux aux petits oignons".
Outre le fait de citer l'apport GNU cela lève une ambiguïté purement technique.

Je viens de me rendre compte que sur un test au moins Firefox éclate largement Chrome.
Quand je vais sur cette page : http://patrickguignot.free.fr/sf/nouvelles_sf.html
Et que je trie sur la colonne "Auteur" (en cliquant sur le titre de colonne) cela met environ 1 seconde (à la louche) sous FF 3.6 et ça met environ 10 secondes (à la louche) sous Chrome 5.0.335.

Bizarre ce truc. Un bug de Chrome sur ce script js particulier (script généré automatiquement par Tellico quand j'ai créé cette page) ?

Et puis il faut le convaincre pour intégrer quelque chose dans le noyau si il n'y a pas d'utilisateurs qui le réclament (cf le mail complet de Linus).
Dans le cas de Nouveau il est évident qu'il y avait beaucoup d'utilisateurs.

Hmm...sur le quant/quand je ne suis pas certain qu'il soit nécessaire de corriger : http://atilf.atilf.fr/dendien/scripts/tlfiv5/visusel.exe?11;(...)
Pareil pour les a/à (mais je suis une quiche en grammaire donc je peux me gourer).

J'ai simplifié en parlant juste de protocoles synchrones et asynchrones.
En fait il y a trois protocoles différents concernant la réplication des données (A, B et C).
Tu peux lire une explication des différences ici : http://www.drbd.org/users-guide-emb/s-replication-protocols.(...)

>>> Plus inquiétant, on va plus vite sous Windows 7 que sous Ubuntu

Comme tu le dis c'est peut-être spécifique au 64 bits (du fait que FF n'optimise pas tracemonkey).
Faudrait comparer en 32 bits...et si c'est toujours à l'avantage de Windows gueuler sur ces salopiots de devs qui optimisent pour l'OS du mal ;-)

Il a fait une tentative pour le 2.6.33 mais sa branche n'a pas été incluse : http://thread.gmane.org/gmane.linux.kernel/929510

On peut être certain qu'il va retenter sa chance pour le 2.6.34.

J'en avait parlé un tout petit peu lors de la news du noyau 2.6.30 ou on voyait apparaître les premiers patchs. C'est vrai que le 2.6.33 ajoute le TRIM dans libata mais bon ça reste encore désactivé par défaut...et puis on ne peut pas parler de tout ;-)

Dans le pdf indiqué en lien ("improving TCP security with robust cookies") on trouve ceci :

"Common DNSSEC-signed responses are as long as 1749 bytes. During key rollover, the response could be more than twice that size, much larger than the default UDP data size of 512 bytes".

>>> les formations que nous recevons ne rentrent pas dans un niveau de détail aussi précis que la distinction entre le web et le non web

Houlà...pourtant c'est basique non ? Il reste quoi à dire dans une formation si on n'évoque même pas ça ?

Corrigé merci.

Groumf. Merci.
C'est quand même effarant cette perversité de l'Univers qui introduit ainsi des myriades des fautes dans mes dépêches innocentes.

>>> tu réponds vite

Je suis en congé aujourd'hui et demain donc je glandouille devant mon ordi ;-)

>>> Je comprends le problème de la fragmentation pour des périphériques avec un temps d'accès lent, typiquement les disques durs avec leur parties mécaniques qui doivent donc se déplacer de fragment en fragment. Mais lors d'accès en RAM, ce problème ne se pose pas. Quel est donc le problème ?

Moi aussi ce truc m'a toujours plus ou moins intrigué. Cela s'explique parce qu'il y a des cas ou il est absolument nécessaire d'allouer une quantité de mémoire contigüe....et évidemment c'est difficile de satisfaire cette condition si toute la mémoire est fragmentée en petits bouts entre les processus.
On trouve pas mal de détails ici : http://lwn.net/Articles/211505/
Notamment ce paragraphe (à la fin rigolote) :
"Since Linux is a virtual memory system, fragmentation normally is not a problem; physically scattered memory can be made virtually contiguous by way of the page tables.
But there are a few situations where physically-contiguous memory is absolutely required. These include large kernel data structures (except those created with vmalloc()) and any memory which must appear contiguous to peripheral devices. DMA buffers for low-end devices (those which cannot do scatter/gather I/O) are a classic example. If a large ("high order") block of memory is not available when needed, something will fail and yet another user will start to consider switching to BSD".

Tel Sisyphe je roule mon rocher. C'est corrigé, merci.