Tout dépend si la carte est bien supportée sous Linux, et sous ta distrib en particulier. Une Adaptec 2400A en Raid 5 avec 3 disques et les drivers génériques est moins performante qu'un disque seul...
Tout à fait.
Dans le genre, j'avais utilisé sur un IBM Netfinity (Bi-P2 700 MHz) une carte ServeRaid 3-L (plutôt bas de gamme) et j'avais été très surpris de constater que 2 disques IBM en RAID-1 (miroir) étaient plus lents qu'un seul. C'était même encore plus bizarre, chaque disque séparément faisant 20 Mo/s de débit nominal (hdparm ou dd), et avec un bon "dd" sur le disque RAID je faisais 10 Mo/s en lecture, et 14 Mo/s en écriture (plus qu'en lecture).
Grosso modo, ext3 et reiserFS se font détruire. Qui l'eu cru ?
Les 2 "gagnants" sont JFS et XFS. Le "perdant" est ext3.
Il faut vraiment prendre ces tests avec précaution, et comprendre ce qui est testé (ici c'est plutôt du bas niveau). Il faut aussi regarder les proportions entre les chiffres, si 2 FS sont à 10% l'un de l'autre, c'est vraiment pas grand chose (à vue de nez, on ne voit pas la différence).
Le vrai test c'est de tester son application (ou ses applications), c'est quand même ça qui compte. J'ai par exemple effectué des tests de bas niveau sur les différents FS, et ensuite j'ai utilisé pgbench (benchmark livré avec PostgreSQL) pour tester du point de vue haut niveau (mon appli faisait surtout des accès base de données). Les différences parfois importantes à bas niveau le sont beaucoup moins avec le test pgbench.
[ affiche parodique du BSA ] Trop dur à imprimer sur du papier blanc !
Je ne te suis pas, on est plusieurs dans ma boîte à avoir imprimé le PDF et ça se passe très bien. Quel problème as-tu ?
Les affiches sont placées sur le mur derrière plusieurs bureaux, bien en évidence :-)
donner le prix et le nombre de pages de chaque magazine [...] On pourrait, comme cela, savoir si "quantitativement" on en a pour son argent.
A ce moment-là, je te conseille l'annuaire téléphonique, le rapport nb de pages / prix est imbattable ! :-)
Plus sérieusement, c'est rarement une question que je me pose. Et tu oublies que dans certains magazines il y a beaucoup de publicités (à ce sujet, certains magazines féminins détiennent la palme).
Mais les meilleurs codecs, surtout en termes de vidéo, sont tous brevetés. La seule possibilité pour l'instant est de donner l'occasion aux gens d'acheter ces codecs sous forme de plugins pour GnomeMeeting.
Un codec étant un logiciel, il n'est pas brevetable ailleurs qu'aux Etats-Unis, non ? (ce que le parlement européen vient de confirmer).
Ce ne sont pas des brevets US qui vont nous empêcher d'utiliser des bons codecs, et ce ne serait pas la première fois.
Qu'en dis-tu, Damien ?
des positions un peu extrèmes (voir même extrémiste)
De grâce, on dit voire, pas "voire même".
Et dire "voir même" ça n'a vraiment aucun sens, il ne s'agit pas du verbe "voir".
Si je me permet de faire la correction, c'est parce que je vois l'erreur trop souvent, j'espère que ce message servira à quelque chose.
Par contre, les clefs à base de compact-flash (presque toute, je crois), sont limitée à 10 000 ecriture.
A ma connaissance, et j'ai vérifié autour de moi (on fait du hard dans ma boîte et on utilise de la Flash), c'est plutôt entre 100 000 et 200 000 écritures. Il s'agit du nombre d'écritures sur un bloc donné de la mémoire, c'est à dire que si tu écris ~100k fois sur le même emplacement, il devient inutilisable. Certaines puces ont un contrôleur un peu intelligent qui réparti les écritures sur tous les blocs, et qui de plus repère les blocs grillés, ce qui allonge d'autant la durée de vie de la mémoire (la clef reste utilisable avec plein de blocs morts, la capicité diminue juste).
Qu'est-ce qu'on a comme format video libre, pas trop lourd, lisible sur toutes les plate-formes, et sans procédure d'installation obscure ?
Je dirais le MPEG.
Pour le MPEG-1, je ne sais pas s'il est plus lourd que le ".ram" ou non, quelqu'un sait ? Il faudrait pouvoir comparer à taille d'image égale et qualité égale, le ".ram" étant souvent utilisé avec des qualités assez moyennes (pour ce que j'ai vu).
Et sinon le MPEG-4, dont je ne sais pas exactement si ça implique un codec précis ou pas, sachant que ça englobe les divers DivX si j'ai bien compris, plus d'autres. En tous cas, ffmpeg le gère, ce qui vu la nature de ce logiciel permet en principe la lecture sur toute plateforme.
J'ai vu des articles intéressants sur le Web sur les clefs USB, avec des comparatifs sur la solidité et les performances. Je n'ai pas gardé les URL mais ça doit être genre hardware.fr, anantech.com ou aceshardware.com (google doit aider).
le temps de transfert pour un gros fichier sur une de ces clés (que ce soit en USB 1.0 ou 2.0)
En USB 1 (12 Mb/s) il me semble que c'était vers 700-800 ko/s pour les bonnes clefs. Il y avait 2 vitesses différentes selon les modèles (sans doute à cause des contrôleurs mémoire).
peut-on booter dessus pour Linux au lieu d'une disquette (je supose dans ce cas que la carte mère le supporte).
Ca dépend du BIOS je crois, donc de la carte mère effectivement.
Il ne faut pas mettre de majuscules à "logiciel libre", je pense que tu es influencé par les américains qui en mettent facilement. Ce n'est pas parce que c'est aussi un concept (et de plus cher à nos coeurs) qu'il faut mettre des majuscules :-)
vous aurez donc maintenant l'opportunité de nous écouter -> "vous aurez donc maintenant la possibilité de nous écouter"
En français, on ne peut pas dire "'avoir l'opportunité", ni "une opportunité", parce que ça s'emploie comme le mot "pertinence". Le sens dans lequel tu l'as utilisé est un anglicisme ("an opportunity" = "une occasion" généralement). On ne peut que parler de l'opportunité d'une décision ou d'un acte, c'est à dire de son caractère opportun (qui vient à point, qui est approprié).
Quand je demande quelle valeur est la bonne, je veux dire :
laquelle de ces deux valeurs correspond au taux de transfert moyen avec mon disque dur ?
Tu fais fort, dans le genre bouché (sans vouloir t'offenser).
Dans un cas j'ai écrit "la mesure donnée est surtout dépendante du disque", dans l'autre "cette donnée ne dépend pas du disque". Je ne peux pas faire plus clair.
En plus, mon seagate devrait fonctionner en udma66, et si la valeur de crête est la première (14.58 Mb/s), ben soit je me suis fait rouler, soit y'a un truc qui cloche...
Ce n'est pas parce que l'interface entre le disque et le contrôleur permet des transferts à 66 MB/s (ne confond pas les bits et les Bytes au fait, il y a un rapport de 1 à 8), que le disque est capable de lire ou d'écrire à cette vitesse. Autant que tu le saches tout de suite, un disque en UDMA133 ne te lira pas tes données à 133 MB/s, en tous cas pas d'ici quelques années (les valeurs courantes sont de l'ordre de 45-60 MB/s).
De toutes façons, le taux de transfert en lecture linéaire (le chiffre que te donne hdparm) ne fait pas tout, le temps d'accès aussi, et même le firmware (cas des disques SCSI pour serveurs, qui sont optimisés pour les accès de type base de données).
un hdparm -t /dev/hda me donne :
Timing buffered disk reads: 64 MB in 4.39 seconds = 14.58 MB/sec
alors qu'un hdparm -T /dev/hda m'indique :
Timing buffer-cache reads: 128 MB in 1.99 seconds = 64.32 MB/sec
C'est écrit dans le texte, mais je vais détailler.
L'option "-t" effectue tout d'abord un "flush" du "buffer-cache" (le cache disque du noyau), ensuite lit le disque (les données sont stockées dans le buffer-cache au passage, fonctionnement normal pour tout "block device"); la mesure données est surtout dépendante du disque, mais un peu de la mémoire et du processeur.
L'option "-T" évalue la vitesse de lecture quand les données sont déjà dans le buffer-cache; cette donnée ne dépend pas du disque, mais du CPU et de la mémoire (des accès mémoires).
l'utilisation de hdparm avec des valeurs sures, car certaines options de hdparm peuvent etre dangereuses.
D'une part, la plupart des distributions activent le DMA IDE par défaut, donc pas besoin de jouer avec hdparm. Je crois que dans le cas de certains chipsets marqués comme buggés, le DMA n'est pas activé par sécurité.
Sinon, du temps où il fallait jouer avec hdparm, les paramètres vraiment importants étaient tout simplement l'activation de la DMA, pour les autres l'influence était à peine significative.
Autrement dit, "hdparm -d 1 /dev/hda" est l'essentiel, et sans danger. On peut aussi ajouter le "multi-sector read" avec "-m 16" (pour la valeur 16, on peut vérifier avec "hdparm -i" en regardant la valeur "MaxMultSect"), ainsi que les transferts en 32 bits ("-c 1"), mais une fois le DMA activé c'est peu mesurable, en tous cas avec les évaluations de "hdparm -t".
Ce qui est censé être moins prudent, c'est de jouer avec l'option "-X" et de demander un mode de DMA non supporté. Sur les machines où ça m'est arrivé, ça a juste bloqué la machine, mais je n'ai rien cassé.
Quels sont les alternatives à ISC BIND (Si c'est aussi évident) libre ou opensource, évidemment ?
Le djbdns est pas mal du tout, mais il n'implémente pas certains trucs. C'est fait par le réputé (en terme de sécurité) Daniel J. Bernstein, un mathématicien. Il a aussi fait qmail. Utilise Google pour l'URL, je ne l'ai pas sous la main.
Je le mentionne car ça dérange certaines, sa licence est un peu particulière car il n'autorise pas la redistribution de ses sources modifiées, seulement des sources + patches. La raison est qu'il garantit son code (il a tout audité soigneusement).
Serait-il possible, que lorsque la discussion s'engage sur l'orthographe, [...], vous changiez le sujet de vos commentaires
Ton commentaire est mal à propos dans le cas présent, vu que j'ai exprès mis un titre différent de celui de la nouvelle (par civilité justement). Je te le rappelle puisqu'il t'a échappé : « fondements de l'Internet » (j'ai souligné les 2 lettres manquantes).
Par ailleurs, j'en profite pour signaler que la nouvelle parue aujourd'hui à 8h du matin porte un titre utilisant la forme propre : « Le rôle des états dans la gestion de l'Internet en question », comme quoi je ne suis pas le seul à prôner cet usage.
En français, on a toujours dit "sur Internet" et pas "sur l'Internet", avant que les académiciens ne mettent leur grain de sel. Je vois mal pourquoi changer.
Et bien non, on n'a pas toujours dit "sur internet", figure-toi. Rien à voir avec les académiciens, dont je ne connais pas la recommandation sur ce sujet. Ce n'est pas parce que quelque journalistes ont lancé l'usage (surprenant comme je l'ai expliqué) que ça doit être retenu pour norme. Le commentaire de "Guillaume G.", en réponse au tien, est très pertinent.
Et l'argument "on ne va pas changer", franchement il ne va pas bien loin. Il me fait penser à ceux qui sont contents sous Windows et qui ne veulent rien changer, ou aux webmestres qui ont des sites IE-only ("à quoi bon, MS/IE/Office sur 95% des machines, etc").
Je suis un peu hors sujet, mais c'est magnifique ce truc (le diff en HTML et en couleur), je découvre (oui je vis sous l'eau, comme disent certains :-). Si j'ai bien saisi, c'est cvsweb qui génère ça ?
C'est peut-être un détail, mais il est préférable de dire « l'Internet » tout comme on dit « le Web ».
Je ne sais pas pourquoi, "the Web" est resté "le Web" en français, mais "on the internet" a été traduit par "sur Internet" (au lieu de "sur l'Internet", logiquement), que je n'aime pas trop, ça ressemble à "sur TF1" comme si c'était un bête canal de réception.
Le lien sur la lettre du sénateur Trégouët pointe sur une très longue page, sur laquelle il n'est pas facile de trouver la partie concernant la position du gouvernement.
Est-ce qu'un modérateur pourrait modifier le lien pour y ajouter simplement "#art4339" ? Ca facilitera les choses pour tout le monde.
Prelink sera dans la prochaine Redhat (Oct 2003).
Pour avoir testé, ça ne change pas grand chose. Du moins pour les programmes en C.
Evidemment, puisque le prelink (appelé initialement "obj-prelink") concerne le C++ !
L'édition de liens en C++ pose tout un tas de problèmes (il y a des articles intéressants à ce sujet, qui ont déjà été mentionnés sur ce site, sinon recherche sur le site de KDE) nettement plus complexes que l'édition de liens en C, qui elle ne pose aucun problème.
[Zinf] Je l'utilise beaucoup sur Windows (et y a quelque bug si tu clique un peu vite, n'importe comment)
J'ai arrêté de l'utiliser sous Windows (dernière version = 2.2.1 depuis longtemps alors que sous Linux c'est la 2.2.4) au boulot à cause d'un bug gênant : quand je lis un ogg, la plupart du temps quand je veux sauter directement à un endroit du morceau, le programme se fige complètement, et met assez longtemps à revenir; si on n'appuie pas sur "stop", je me demande même s'il finit par revenir.
Du coup je suis passé à SnackAmp (cf sourceforge) qui est pas mal pour gérer plein de morceaux.
[^] # Re: Benchmarks 'compréhensibles' des systèmes de fichiers sous Linux
Posté par Olivier Jeannet . En réponse à la dépêche Benchmarks 'compréhensibles' des systèmes de fichiers sous Linux. Évalué à 1.
Tout à fait.
Dans le genre, j'avais utilisé sur un IBM Netfinity (Bi-P2 700 MHz) une carte ServeRaid 3-L (plutôt bas de gamme) et j'avais été très surpris de constater que 2 disques IBM en RAID-1 (miroir) étaient plus lents qu'un seul. C'était même encore plus bizarre, chaque disque séparément faisant 20 Mo/s de débit nominal (hdparm ou dd), et avec un bon "dd" sur le disque RAID je faisais 10 Mo/s en lecture, et 14 Mo/s en écriture (plus qu'en lecture).
[^] # Re: compréhensibles ?!?!?
Posté par Olivier Jeannet . En réponse à la dépêche Benchmarks 'compréhensibles' des systèmes de fichiers sous Linux. Évalué à 6.
Les 2 "gagnants" sont JFS et XFS. Le "perdant" est ext3.
Il faut vraiment prendre ces tests avec précaution, et comprendre ce qui est testé (ici c'est plutôt du bas niveau). Il faut aussi regarder les proportions entre les chiffres, si 2 FS sont à 10% l'un de l'autre, c'est vraiment pas grand chose (à vue de nez, on ne voit pas la différence).
Le vrai test c'est de tester son application (ou ses applications), c'est quand même ça qui compte. J'ai par exemple effectué des tests de bas niveau sur les différents FS, et ensuite j'ai utilisé pgbench (benchmark livré avec PostgreSQL) pour tester du point de vue haut niveau (mon appli faisait surtout des accès base de données). Les différences parfois importantes à bas niveau le sont beaucoup moins avec le test pgbench.
[^] # Re: Ne pas oublier cette superbe affiche !
Posté par Olivier Jeannet . En réponse à la dépêche La BSA organise sa semaine du "Logiciel professionnel". Évalué à 1.
Je ne te suis pas, on est plusieurs dans ma boîte à avoir imprimé le PDF et ça se passe très bien. Quel problème as-tu ?
Les affiches sont placées sur le mur derrière plusieurs bureaux, bien en évidence :-)
[^] # Re: Revue de Presse - Octobre 2003
Posté par Olivier Jeannet . En réponse à la dépêche Revue de Presse - Octobre 2003. Évalué à 2.
A ce moment-là, je te conseille l'annuaire téléphonique, le rapport nb de pages / prix est imbattable ! :-)
Plus sérieusement, c'est rarement une question que je me pose. Et tu oublies que dans certains magazines il y a beaucoup de publicités (à ce sujet, certains magazines féminins détiennent la palme).
[^] # Re: C'était déjà dans les journaux linuxfr le 27/9
Posté par Olivier Jeannet . En réponse à la dépêche Faille de sécurité exploitable à distance dans mplayer. Évalué à 2.
je te conseille d'ailleurs vivement de désinstaller cette librairie si peu utile :-))
Je crois que tu confonds la glib avec la libc (autrement connue comme "glibc" quand il s'agit de celle de GNU)
[^] # Re: Sortie de Gaim 0.69 et 0.70
Posté par Olivier Jeannet . En réponse à la dépêche Sortie de Gaim 0.69 et 0.70. Évalué à 1.
Un codec étant un logiciel, il n'est pas brevetable ailleurs qu'aux Etats-Unis, non ? (ce que le parlement européen vient de confirmer).
Ce ne sont pas des brevets US qui vont nous empêcher d'utiliser des bons codecs, et ce ne serait pas la première fois.
Qu'en dis-tu, Damien ?
[^] # Re: 20 ans déjà
Posté par Olivier Jeannet . En réponse à la dépêche 20 ans déjà. Évalué à 0.
De grâce, on dit voire, pas "voire même".
Et dire "voir même" ça n'a vraiment aucun sens, il ne s'agit pas du verbe "voir".
Si je me permet de faire la correction, c'est parce que je vois l'erreur trop souvent, j'espère que ce message servira à quelque chose.
[^] # Re: Bench comparatifs entre les kernel 2.4 et 2.6
Posté par Olivier Jeannet . En réponse à la dépêche Tests comparatifs entre les noyaux 2.4 et 2.6. Évalué à 5.
Et voilà :
The Wonderful World of Linux 2.6 (by Joseph Pranevich)
http://www.kniggit.net/wwol26.html(...)
et la traduction en français :
Le monde merveilleux de Linux 2.6
http://dsoulayrol.free.fr/articles/wonderful_2.6.html(...)
[^] # Re: Les clefs USB sont
Posté par Olivier Jeannet . En réponse au sondage Les clefs USB sont. Évalué à 8.
A ma connaissance, et j'ai vérifié autour de moi (on fait du hard dans ma boîte et on utilise de la Flash), c'est plutôt entre 100 000 et 200 000 écritures. Il s'agit du nombre d'écritures sur un bloc donné de la mémoire, c'est à dire que si tu écris ~100k fois sur le même emplacement, il devient inutilisable. Certaines puces ont un contrôleur un peu intelligent qui réparti les écritures sur tous les blocs, et qui de plus repère les blocs grillés, ce qui allonge d'autant la durée de vie de la mémoire (la clef reste utilisable avec plein de blocs morts, la capicité diminue juste).
[^] # Re: Berners-Lee : The Future of the World Wide Web
Posté par Olivier Jeannet . En réponse à la dépêche Berners-Lee : The Future of the World Wide Web. Évalué à 1.
Je dirais le MPEG.
Pour le MPEG-1, je ne sais pas s'il est plus lourd que le ".ram" ou non, quelqu'un sait ? Il faudrait pouvoir comparer à taille d'image égale et qualité égale, le ".ram" étant souvent utilisé avec des qualités assez moyennes (pour ce que j'ai vu).
Et sinon le MPEG-4, dont je ne sais pas exactement si ça implique un codec précis ou pas, sachant que ça englobe les divers DivX si j'ai bien compris, plus d'autres. En tous cas, ffmpeg le gère, ce qui vu la nature de ce logiciel permet en principe la lecture sur toute plateforme.
[^] # Re: Les clefs USB sont
Posté par Olivier Jeannet . En réponse au sondage Les clefs USB sont. Évalué à 2.
le temps de transfert pour un gros fichier sur une de ces clés (que ce soit en USB 1.0 ou 2.0)
En USB 1 (12 Mb/s) il me semble que c'était vers 700-800 ko/s pour les bonnes clefs. Il y avait 2 vitesses différentes selon les modèles (sans doute à cause des contrôleurs mémoire).
peut-on booter dessus pour Linux au lieu d'une disquette (je supose dans ce cas que la carte mère le supporte).
Ca dépend du BIOS je crois, donc de la carte mère effectivement.
[^] # Re: Quel serveur alors ?
Posté par Olivier Jeannet . En réponse à la dépêche Faille de sécurité dans ProFTPD. Évalué à 1.
Qu'est-ce que le fxp, et à quoi ça sert ?
Merci de tes explications.
# corrections
Posté par Olivier Jeannet . En réponse à la dépêche Carte blanche aux Logiciels Libres N° 4 : Le Libre et l'Éducation. Évalué à 1.
Il ne faut pas mettre de majuscules à "logiciel libre", je pense que tu es influencé par les américains qui en mettent facilement. Ce n'est pas parce que c'est aussi un concept (et de plus cher à nos coeurs) qu'il faut mettre des majuscules :-)
vous aurez donc maintenant l'opportunité de nous écouter -> "vous aurez donc maintenant la possibilité de nous écouter"
En français, on ne peut pas dire "'avoir l'opportunité", ni "une opportunité", parce que ça s'emploie comme le mot "pertinence". Le sens dans lequel tu l'as utilisé est un anglicisme ("an opportunity" = "une occasion" généralement). On ne peut que parler de l'opportunité d'une décision ou d'un acte, c'est à dire de son caractère opportun (qui vient à point, qui est approprié).
[^] # Re: Pour un boot plus rapide de Linux
Posté par Olivier Jeannet . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 2.
laquelle de ces deux valeurs correspond au taux de transfert moyen avec mon disque dur ?
Tu fais fort, dans le genre bouché (sans vouloir t'offenser).
Dans un cas j'ai écrit "la mesure donnée est surtout dépendante du disque", dans l'autre "cette donnée ne dépend pas du disque". Je ne peux pas faire plus clair.
En plus, mon seagate devrait fonctionner en udma66, et si la valeur de crête est la première (14.58 Mb/s), ben soit je me suis fait rouler, soit y'a un truc qui cloche...
Ce n'est pas parce que l'interface entre le disque et le contrôleur permet des transferts à 66 MB/s (ne confond pas les bits et les Bytes au fait, il y a un rapport de 1 à 8), que le disque est capable de lire ou d'écrire à cette vitesse. Autant que tu le saches tout de suite, un disque en UDMA133 ne te lira pas tes données à 133 MB/s, en tous cas pas d'ici quelques années (les valeurs courantes sont de l'ordre de 45-60 MB/s).
De toutes façons, le taux de transfert en lecture linéaire (le chiffre que te donne hdparm) ne fait pas tout, le temps d'accès aussi, et même le firmware (cas des disques SCSI pour serveurs, qui sont optimisés pour les accès de type base de données).
[^] # Re: Pour un boot plus rapide de Linux
Posté par Olivier Jeannet . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 2.
Timing buffered disk reads: 64 MB in 4.39 seconds = 14.58 MB/sec
alors qu'un hdparm -T /dev/hda m'indique :
Timing buffer-cache reads: 128 MB in 1.99 seconds = 64.32 MB/sec
C'est écrit dans le texte, mais je vais détailler.
L'option "-t" effectue tout d'abord un "flush" du "buffer-cache" (le cache disque du noyau), ensuite lit le disque (les données sont stockées dans le buffer-cache au passage, fonctionnement normal pour tout "block device"); la mesure données est surtout dépendante du disque, mais un peu de la mémoire et du processeur.
L'option "-T" évalue la vitesse de lecture quand les données sont déjà dans le buffer-cache; cette donnée ne dépend pas du disque, mais du CPU et de la mémoire (des accès mémoires).
[^] # Re: Pour un boot plus rapide de Linux
Posté par Olivier Jeannet . En réponse à la dépêche Pour un démarrage plus rapide de Linux. Évalué à 1.
D'une part, la plupart des distributions activent le DMA IDE par défaut, donc pas besoin de jouer avec hdparm. Je crois que dans le cas de certains chipsets marqués comme buggés, le DMA n'est pas activé par sécurité.
Sinon, du temps où il fallait jouer avec hdparm, les paramètres vraiment importants étaient tout simplement l'activation de la DMA, pour les autres l'influence était à peine significative.
Autrement dit, "hdparm -d 1 /dev/hda" est l'essentiel, et sans danger. On peut aussi ajouter le "multi-sector read" avec "-m 16" (pour la valeur 16, on peut vérifier avec "hdparm -i" en regardant la valeur "MaxMultSect"), ainsi que les transferts en 32 bits ("-c 1"), mais une fois le DMA activé c'est peu mesurable, en tous cas avec les évaluations de "hdparm -t".
Ce qui est censé être moins prudent, c'est de jouer avec l'option "-X" et de demander un mode de DMA non supporté. Sur les machines où ça m'est arrivé, ça a juste bloqué la machine, mais je n'ai rien cassé.
[^] # Re: Alternative à OpenSSH
Posté par Olivier Jeannet . En réponse à la dépêche Faille Sendmail et vulnérabilité OpenSSH. Évalué à 2.
Le djbdns est pas mal du tout, mais il n'implémente pas certains trucs. C'est fait par le réputé (en terme de sécurité) Daniel J. Bernstein, un mathématicien. Il a aussi fait qmail. Utilise Google pour l'URL, je ne l'ai pas sous la main.
Je le mentionne car ça dérange certaines, sa licence est un peu particulière car il n'autorise pas la redistribution de ses sources modifiées, seulement des sources + patches. La raison est qu'il garantit son code (il a tout audité soigneusement).
[^] # Re: orthographe
Posté par Olivier Jeannet . En réponse à la dépêche VeriSign détruit l'un des fondements d'Internet. Évalué à 0.
Ton commentaire est mal à propos dans le cas présent, vu que j'ai exprès mis un titre différent de celui de la nouvelle (par civilité justement). Je te le rappelle puisqu'il t'a échappé : « fondements de l'Internet » (j'ai souligné les 2 lettres manquantes).
Par ailleurs, j'en profite pour signaler que la nouvelle parue aujourd'hui à 8h du matin porte un titre utilisant la forme propre : « Le rôle des états dans la gestion de l'Internet en question », comme quoi je ne suis pas le seul à prôner cet usage.
[^] # Re: fondements d<span style="text-decoration: underline">e l</span>'Internet
Posté par Olivier Jeannet . En réponse à la dépêche VeriSign détruit l'un des fondements d'Internet. Évalué à 1.
Et bien non, on n'a pas toujours dit "sur internet", figure-toi. Rien à voir avec les académiciens, dont je ne connais pas la recommandation sur ce sujet. Ce n'est pas parce que quelque journalistes ont lancé l'usage (surprenant comme je l'ai expliqué) que ça doit être retenu pour norme. Le commentaire de "Guillaume G.", en réponse au tien, est très pertinent.
Et l'argument "on ne va pas changer", franchement il ne va pas bien loin. Il me fait penser à ceux qui sont contents sous Windows et qui ne veulent rien changer, ou aux webmestres qui ont des sites IE-only ("à quoi bon, MS/IE/Office sur 95% des machines, etc").
[^] # Re: Sortie de Open SSH 3.7
Posté par Olivier Jeannet . En réponse à la dépêche Sortie de Open SSH 3.7. Évalué à 2.
Je suis un peu hors sujet, mais c'est magnifique ce truc (le diff en HTML et en couleur), je découvre (oui je vis sous l'eau, comme disent certains :-). Si j'ai bien saisi, c'est cvsweb qui génère ça ?
# fondements d<span style="text-decoration: underline">e l</span>'Internet
Posté par Olivier Jeannet . En réponse à la dépêche VeriSign détruit l'un des fondements d'Internet. Évalué à -4.
Je ne sais pas pourquoi, "the Web" est resté "le Web" en français, mais "on the internet" a été traduit par "sur Internet" (au lieu de "sur l'Internet", logiquement), que je n'aime pas trop, ça ressemble à "sur TF1" comme si c'était un bête canal de réception.
[^] # Re: Pétition pour le retour du Samouille
Posté par Olivier Jeannet . En réponse au journal Je quitte LinuxFR. Évalué à 1.
Reviens, Sam< !
# Lien à affiner (modérateur)
Posté par Olivier Jeannet . En réponse à la dépêche Brevets logiciels : conférence, manifestation, soutiens et positions. Évalué à 2.
Est-ce qu'un modérateur pourrait modifier le lien pour y ajouter simplement "#art4339" ? Ca facilitera les choses pour tout le monde.
[^] # Re: Test de la Gentoo 1.4
Posté par Olivier Jeannet . En réponse à la dépêche Test de la Gentoo 1.4. Évalué à 2.
Pour avoir testé, ça ne change pas grand chose. Du moins pour les programmes en C.
Evidemment, puisque le prelink (appelé initialement "obj-prelink") concerne le C++ !
L'édition de liens en C++ pose tout un tas de problèmes (il y a des articles intéressants à ce sujet, qui ont déjà été mentionnés sur ce site, sinon recherche sur le site de KDE) nettement plus complexes que l'édition de liens en C, qui elle ne pose aucun problème.
[^] # Re: j'veux écouter de la musique !
Posté par Olivier Jeannet . En réponse au journal j'veux écouter de la musique !. Évalué à 1.
J'ai arrêté de l'utiliser sous Windows (dernière version = 2.2.1 depuis longtemps alors que sous Linux c'est la 2.2.4) au boulot à cause d'un bug gênant : quand je lis un ogg, la plupart du temps quand je veux sauter directement à un endroit du morceau, le programme se fige complètement, et met assez longtemps à revenir; si on n'appuie pas sur "stop", je me demande même s'il finit par revenir.
Du coup je suis passé à SnackAmp (cf sourceforge) qui est pas mal pour gérer plein de morceaux.