patrick_g a écrit 6448 commentaires

>>> 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.

Merci beaucoup, c'est corrigé.

>>> C'est une limitation de la technologie web. J'avais lu que CSS3 permettrait ça mais j'ai l'impression que ce n'est pas implémenté ou que personne ne l'utilise :-/

Ah ! Mais alors là, hop, je sors l'extension Firefox Readability que m'a fait découvrir nilux_ ici : https://linuxfr.org/comments/1107415.html#1107415

C'est vraiment excellent ce truc car tu peux changer la taille des marges (ainsi que le style général et la taille de la police).
Regarde par exemple ce screenshot avec une grande taille de marge : http://www.flickr.com/photos/11384633@N00/4386576125/sizes/l(...)
Pas mal non pour éviter d'avoir des lignes trop longues ? Et encore je suis en "wide" comme marges et pas en "extra wide".

>>> je pense par exemple que l'interview de Frédéric serait une très bonne dépêche à part entière.

Bon sur ce point là il semble que la majorité des lecteurs sont d'accord avec toi. Je crois que c'est l'effet d'allongement de la news qui provoque cette réaction et pas intrinsèquement le fait d'inclure une interview. Par exemple dans la future dépêche GCC 4.5 il y a aussi une interview incluse mais comme la news est bien plus courte que celle sur le noyau cela l'enrichit et ne la dessert pas amha.

En fait, d'après ce que j'ai compris, les noeuds peuvent être configurés de deux façons différentes.
Soit ils sont de type "noeud primaire" (et alors ils ont le droit de modifier les données), soit ils sont de type "noeud secondaire" (et alors ils ont un rôle purement passif).
Après si tu veux monter une configuration avec un primaire et un secondaire il n'y a pas de problème à utiliser un système de fichiers local (Ext3 par exemple).
En revanche si tu veux une config avec deux noeuds primaires (dual-primary) alors il te faut un système de fichiers distribué à la GFS.

Voir ici :
http://www.drbd.org/users-guide/ch-features.html#s-single-pr(...)
http://www.drbd.org/users-guide/s-dual-primary-mode.html

>>> Par contre, sauf si j'ai raté le lien-qui-va-bien, c'est ensuite la galère quand on revient plus tard lire les nouveaux commentaires : on ne peut pas y accéder directement, il faut d'abord sauter toute la dépêche. Mais c'est un éventuel problème du site, pas du tout de tes textes.

Si j'ai bien compris ce que tu veux dire il te suffit d'activer la barre d'outils du site (tu cliques d'abord sur ton lien "Modifier vos préférences" et ensuite tu coches la barre d'outil).
Ensuite tu pourra cliquer sur les petites flèches en bas à droite de l'écran pour naviguer dans les nouveaux commentaires.
Regarde cette copie d'écran : http://www.flickr.com/photos/11384633@N00/4387089214/sizes/o(...)

Lors de la phase de relecture il y a eu des discussions sur la mailing-list modéros en raison de la longueur inhabituelle de cette news. La question qui se posait c'était de savoir si une borne n'avait pas été franchie.
Comme l'a écrit un des participants à la discussion en découvrant la taille de la dépêche: "Le problème est que ça coupe tout simplement l'envie de lire".

Si je regarde la longueur des dépêches noyau j'obtiens ceci (en me basant sur ce qu'indique la ligne Linuxfr juste en dessous des liens de la news) :

2.6.24 => 33 614 caractères
2.6.25 => 34 938 caractères
2.6.26 => 27 383 caractères
2.6.27 => 45 996 caractères
2.6.28 => 36 479 caractères
2.6.29 => 37 616 caractères
2.6.30 => 54 211 caractères
2.6.31 => 68 189 caractères
2.6.32 => 73 197 caractères
2.6.33 => 100 088 caractères

On constate donc que jusqu'au 2.6.29 ça oscille gentiment entre 35k et 45k caractères. L'inflation réelle commence avec le 2.6.30 et n'a fait qu'augmenter depuis (même si la taille vraiment inhabituelle de la news 2.6.33 s'explique aussi par l'inclusion de l'interview de Frédéric).
Donc des questions se posent auxquelles j'aimerais, gentil lecteur, que tu répondes:

1) Est-ce que c'est trop long à lire ou pas ?
2) Si oui qu'est-ce qu'il faut enlever ?
3) Z'avez d'autres suggestions ?