patrick_g a écrit 6387 commentaires

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 ?

>>> Bon, dans ce cas : "ont peut penser que le déploiement"

Ouch elle était vilaine celle là :-\
Merci.

Tiens en voilà une illustration...

s/me/même

>>> Je pense que tu voulais parler de CFQ.

Argh tu a raison. Coquille corrigé, merci.

>>> Enfin bon je cherche des poux hein?

Pas du tout, c'est bien d'avoir des retours sur les erreurs et typos de la news...me si ça fait mal au coeur d'avoir laissé passé des bêtises en dépit de x relectures.

>>> Ah oui, le latin. Cette langue que certains disent morte alors qu'on l'entend à la radio finlandaise, sans même parler de son utilisation à l'écrit.
>>> Ce que tu négliges également, c'est tout le côté artistique et culturel

Pourtant le monsieur a bien précisé : "plutôt que d'apprendre une langue comme le mandarin, le russe, ou toute autre langue ayant au moins une littérature conséquente".
Donc il ne néglige pas du tout le coté culturel.

Un post très intéressant. Merci beaucoup pour ces infos...même si ça fait un peu douche froide pour les libristes exaltés :-)

>>> Dans un premier temps tu peux essayer l'extension Readability pour Firefox qui reformatte les pages pour les rendre plus lisibles

Excellente cette extension ! Merci beaucoup.

Juste un petit mail pour dire que j'ai envoyé quelques questions à Harald au sujet d'OsmocomBB et que j'espère pouvoir traduire ses réponses et poster rapidement une dépêche faisant suite à celle-ci.
AMHA c'est un projet tellement intéressant que ça mérite de creuser un peu le sujet.

>>> En tout cas, je souhaite une longue vie a OsmocomBB et j'espere sincerement me tromper. Mais la situation etant tellement glauque dans la telephonie que j'arrive pas a etre optimiste sur ce genre d'initiative...

Première possibilité : Cela va peut-être abaisser un peu la barrière d'entrée pour des petits constructeurs de matos.
Un fabricant taïwanais veut produire une série de téléphones pas chers ? Hop il met OsmocomBB pour gérer le chipset GSM et Linux pour le reste. Pas besoin de payer une pile GSM proprio. C'est un avantage comparatif par rapport à ses concurrents...et ça les entreprises aiment !

Seconde possibilité : Je n'en sais rien du tout mais est-ce vraiment réservé aux entreprises ? Ce n'est pas possible pour un particulier de flasher la pile GSM du baseband chipset ? Cela doit sans doute être actuellement difficile (comme il était difficile d'installer une distro dans les années 90) mais des mécanismes d'installation plus simples vont peut-être devenir disponibles ?

Je fais confiance aux sorciers du marketing Microsoft pour avoir bien étudié la question à l'avantage de leur boite.

>>> Moi ça me fait toujours bizarre que des politiques rejoignent le privé quand ils n'en viennent pas.

Je suis d'accord avec toi mais d'un autre côté quand un politique retourne dans son corps de fonctionnaires duquel il était détaché (Inspection des finances, Conseil d'Etat, etc) on crie au scandale car ces gens ne prennent aucun risque et ont leur place au chaud qui les attends toute leur vie.

>>> Dix minutes plus tard, on vous propose d'installer des drivers propriétaires éventuels (exemple nvidia), vous répondez encore "oui",

Heu...là il faut plutôt répondre "non".