Olivier Jeannet a écrit 1400 commentaires

C'est pour rappeler simplement que dire encodage c'est très moche (mais toléré) et que le terme normal c'est codage (avec "encoding" en anglais les gens ont pris le mauvais pli).
A noter que "codec" = "codeur/décodeur", qu'on parle de "message codé" (et non encodé), de "codage PAL" ou de "codage préfixe", etc.

gimp2 [...] prépare son code à migrer vers gegl

Qu'est-ce que ce "gegl" ?
(si tu as fait une faute de frappe, je n'ai pas réussi à trouver de quoi il pouvait s'agir)

PS: on dit "une icône", donc "accompagnés d'une icône représentative" (pour ton commentaire http://linuxfr.org/comments/325527.html(...) daté du 07/01/2004 23:09)

Cette phrase extraite de l'interview : « En 2004, tout dépendra de comment vont s'équilibrer les lobbying respectifs ».

c'est quand même vraiment insultant pour l'intelligence et la compétence des députés européens que de dire une chose pareille !

Ca ne me choque pas tant que ça, car il s'agit d'un domaine (les brevets logiciels) qui n'est pas évident à appréhender, même pour des gens qui connaissent un peu le monde du logiciel. Imagine que tu deviennes député, tu aurais à voter sur des questions que tu connais à peine.
La grande majorité des députés ne doit pas connaître le domaine du développement logiciel, et quand ils cherchent à se faire une idée sur la question, ils se font forcément influencer par les différents lobbying en place (qui jouent leur rôle).

[...] capable de streamer des flux MPEG [...]
Rappel : streamer consiste à diffuser de la vidéo sur réseau. Désolé d'avoir conservé le terme anglais mais je n'ai pas trouvé aussi bien en français.

Au minimum, il faut écrire ce mot en italique, car il s'agit d'un mot étranger, et ça rend la lecture plus claire.

De plus, une traduction tout à fait satisfaisante est celle proposée, à savoir diffuser : [...] capable de diffuser des flux MPEG [...].

De toutes facons, avec tout ce beau monde qui couine, le brevet ne va pas tenir bien longtemps.

Une chose m'échappe, c'est comment ça se fait que MS, avec tous ses moyens (financiers et d'influence), n'ait pas réussi à obtenir le réexamen de ce brevet, depuis le temps que dure le procès ? Ils ont pourtant de sacrés avocats et lobbyistes. Si quelqu'un a une piste...

La bonne nouvelle, c'est que dans cette histoire le W3C semble avoir plus d'influence que MS (ça doit probablement être la 1ère fois !) dans le monde commercial.

Le principe de fixation d'un mat sur une planche à voile est breveté.

C'est la technique utilisée (et ce qui est mis en oeuvre) pour fixer un mat sur une planche à voile qui est brevetée, pas le principe en lui-même. Il existe probablement à l'heure actuelle (là je m'avance un peu) plus d'un brevet sur la façon de le faire, avec l'évolution des matériaux, et le fait que d'autres gens ont dû se creuser la tête pour trouver une autre méthode.

brevet qui a expire aux USA mais pas partout dans le monde!

De toutes façons il ne peut expirer qu'aux USA et au Japon, vu qu'il s'agit d'un brevet logiciel (un algorithme de compression).
A noter que l'algorithme de compression utilisé par le PNG (et la zlib) est une petite variante de la compression LZW, comme quoi c'est vraiment débile ces brevets sur des algorithmes.

D'ailleurs je n'ai pas compris cette partie de l'article de ZDNet :
le brevet LZW est arrivé à expiration aux États-Unis, en juin dernier. Unisys ne compte pas le renouveler, mais en aura toutefois la jouissance jusqu’à la mi-2004 dans différents pays (Canada, Japon, Royaume-Uni, Allemagne, France et Italie).
"Royaume-Uni, Allemagne, France et Italie", ils rêvent chez ZDNet...
J'ai essayé de laisser un commentaire mais ça n'a pas l'air de marcher.

> procédures stockées, aux triggers, à la conformité au langage SQL (sub-select par exemple).
Ces fonctionnalités seront implémentées d'ici 6 à 12 mois

Ca fait un bout de temps que MySQL promet d'implémenter tout ce qui manque pour en faire une réelle base relationnelle avec contrôle d'intégrité. En pratique, tout ça met beaucoup de temps à venir (ça fait longtemps que je m'intéresse à la question). Mais je ne dénigre pas MySQL, qui a ses vertus et qui peut être préféré à PostgreSQL selon les cas.

essaie d'installer PostgreSQL sous windows et on en reparle, tu me diras combien de temps tu as mis.

Je n'ai pas essayé et je ne vois pas trop l'intérêt personnellement. Mais ça se fait avec Cygwin assez facilement.

Pour les benchs, c toujours le problème de savoir comment les prendre...

Je n'ai pas donné les résultats du bench, j'ai justement eu le problème que mon bench ne marchait pas comme il fallait, comme si les accès simultanés en "update" ne marchaient pas avec MySQL (et table InnoDB bien sûr). Je n'exclus pas une erreur de ma part mais j'ai fait attention.

Il a vraiment tout pour gagner sauf les deux trois fonctionnalités qu'il aura en début d'année prochaine.

Tu es vraiment optimiste, on peut prendre les paris si tu veux :-)

[MySQL] Il lui manque juste deux trois fonctionnalités qu'il aura rapidement et qui lui permettront d'être préférés à PotsgreSQL.

Tu vas vite en besogne. Il manque pas mal de choses non triviales à MySQL pour arriver au niveau des possibilités de PostgreSQL, je pense en particulier aux procédures stockées, aux triggers, à la conformité au langage SQL (sub-select par exemple).

Concernant la facilité d'utilisation, PostgreSQL est vraiment très simple à installer et à utiliser (je l'ai même fait plusieurs fois depuis les sources, pour avoir rapidement la dernière version). Je ne l'ai jamais vu planter en 3 ans.

Ayant voulu comparer il y a quelques mois les performances de MySQL et PostgreSQL (avec un bench assez simple, pgbench, qui est livré avec PostgreSQL; je l'ai modifié pour qu'il tourne avec MySQL), j'ai eu des soucis lors des accès simultanés, MySQL me faisait des "deadlocks". Ca ne m'a pas donné envie de continuer. J'ai bien entendu comparé les dernières versions de ces 2 bases.

Je pense que les avantages que je trouve à MySQL l'ont propulsé numéro 1, ce n'est pas une mode.

A mon avis, c'est surtout qu'il y a quelques années il était très rapide pour des bases simples avec peu de modifications et beaucoup de lectures, cas typique d'un site Web; et PostgreSQL était moins fort pour ça. Il a bénéficié ainsi d'une avance initiale, et d'une certaine publicité, sans doute aidé par la société qui est derrière, alors que PostgreSQL quasiment pas. Mais depuis un bout de temps, PostgreSQL n'a pas à rougir de ses performances, et surtout est beaucoup plus puissant qu'une simple base de données accolée à un site Web.
En fait les 2 bases ne jouent pas dans la même cours.

J'ai parfois l'impression que le fait que ce soit MySQL qui est mis en avant (au lieu de PostgreSQL) est aussi arbitraire que pour Linux face à BSD (je ne dis pas qu'un OS est meilleur que l'autre).

Si jamais la dame qui appelle sait que son appel est dispo sur le net

Vu qu'elle a insisté pour que son appel soit enregistré, elle a pris un risque...

- Il faut enregistrer mon appel, là
- Il est enregistré madame, tous nos appels sont enregistrés (il doit déjà sourire sous cape en pensant à le faire écouter à ses collègues ;)

En général un simple cat /proc/pci suffit pour avoir déjà énormément d'info

C'est pratique mais un peu bas niveau, on peut avoir un résultat plus synthétique et en clair avec la commande "lspci".

par exemple, "cat /proc/pci" donne ceci :
..Bus 0, device 8, function 0:
....Class 0100: PCI device 9004:8178 (rev 1).
......[...]
..Bus 1, device 0, function 0:
....Class 0300: PCI device 102b:0525 (rev 4).
......[...]

alors que "lspci" donne :
00:08.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U (rev 01)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04)

Typiquement quand on lit des entrées physiques tout ou rien, c'est plutôt toutes les 10 ms (pooling).

C'est n'est pas du pooling (regroupement, mise en commun) mais du polling (interrogation régulière, attente active).
Bon tu n'es pas le premier à confondre les deux (au moins pour l'orthographe).

Il n'est pas question de s'attirer des ennuis pour une connerie pareille.

Quels ennuis ?

Je trouve ça franchement nul (et je suis surtout très surpris) d'avoir censuré les URL, alors qu'il suffisait d'enlever le http:/ qui est devant, et de prévenir de la conséquence si on le colle dans IE. Les gens sont responsables quand même !

Ben justement, le firewall sur une machine perso, rien de plus simple :

Tu refuse ce qui viens de dehors

Je ne vois pas l'intérêt d'un firewall pour une machine perso tout simple. Pourquoi refuser des connexions externes puisque je n'ai aucun serveur en écoute ? En fait, j'ai SSH, mais justement je veux y accéder de l'extérieur (sinon je vois mal à quoi il servirait !).

J'irai meme jusqu'à dire qu'une machine perso allumée souvent, avec l'ADSL et sans firewall, c'est du suicide.

J'ai l'ADSL, ordi allumé 24h/24, et je n'ai pas de firewall. Et je ne pense pas qu'un firewall qui bloquerait en entrée tous les ports sauf le 22 (SSH) améliorerait ma sécurité.

http://www.megatokyo.de/?lang=fr&id=9(...)

J'avais déjà repéré ce dessin en VO, je le trouve assez amusant.
Dommage qu'ils n'aient pas traduit la dernière bulle. Il est vrai que traduire "yo" n'est pas évident, mais j'aurais mis "M01" tout simplement.

> Mais bien sur, les constructeurs vont vendre des pc avec un firewall par defaut...
Moi j'en connais un qui va etre surpris dans quelques mois...

Ca devient n'importe quoi l'informatique grand public ! (je ne dis pas ça spécialement pour toi pBpG, j'apprécie généralement tes commentaires)

Avoir un ordinateur personnel (sans machines à protéger derrière, utilité principale d'un firewall) qui a besoin d'un firewall, mais où ça va... Et dire que les windowsiens trouvent ça normal et n'imaginent plus un PC sans firewall; il n'y a qu'à parcourir les forums pour voir les discussions : "j'ai installé la dernière version de Zone Alarm / firebidule", etc.. (sans parler du dernier anti-virus et du dernier anti-spyware, les mecs ne se rendent pas compte du délire que c'est devenu, Windows). Bon j'arrête ou je vais tomber en panne de points d'exclamations !

En l'occurence le HTML *EST* une norme (établie à l'ISO)

Je n'en suis pas si sûr, aurais-tu une URL à ce sujet ? (ou bien la norme ISO précise)
D'ailleurs je ne pense pas que le HTML (tout court) puisse être une norme ISO, ce qui pourrait éventuellement être une norme ISO c'est une version bien précise du HTML (3.2, 4.01), ou plutôt du XHTML. Et encore, ça m'étonne, je pense plutôt que ce serait le XML.

J'approuve entièrement ce genre de démarche, cependant quelques remarques :
- j'espère que les accents sont arrivés au destinataire sinon ça va finir direct à la poubelle (au fait comment n'as-tu pas vu à la prévisualisation qu'ils n'étaient pas là ?)
- ce qui est émis par le W3C ce sont des recommandations et non des normes; disons qu'elles sont censées être des standards
- tu parles de "pécule (?) des citoyens français" : difficile car les accents manquent, mais l'expression est bizarre si c'est ça, je dirais "argent" tout simplement
- "sans discrimination matérielle" -> j'aurais dit "logicielle" plutôt
- palier ce problème : "pallier ce problème"

[ PNG] mais très limité quant à la plage de couleur

N'importe quoi, le PNG gère les images à palette (couleurs indexées) tout comme les images en 24 bits, voire plus (jusqu'en 48 bits si je ne m'abuse). Pour les images à palette, on a le choix entre 2 (monochrome), 4, 16 et 256 couleurs possibles.

Un coup d'oeil à cette URL devrait t'apprendre des choses : http://www.w3.org/Graphics/PNG/(...)

Pour répondre à ce qui est dit aussi plus haut, le GIF et le PNG font de la compression sans perte, mais le PNG comprime mieux de 10% en moyenne (pour moi c'est rare que le PNG prenne plus, souvent nettement moins). Le PNG utilise la compression "zlib", la même que gzip (on peut régler le niveau de 1 à 9). Je transforme systématiquement les GIF que je reçois en PNG (le PNG est de toutes façons plus propre, plus riche et c'est un standard du W3C).

C'est le JPEG qui tire parti des propriétés de l'oeil humain pour comprimer (assez bien) avec des pertes relativement peu visibles.

Permets-moi de te suggérer un gros effort sur l'orthographe, sinon ton rapport risque d'en pâtir.

-> je dois
-> élection
-> y a-t-il
-> cas des élections présidentielles
-> par préférence

Les perfs sont vraiments etranges:
* avec la Tekram: si je fais de longues ecritures, la commande dd me rend la main tres vite, mais ma machine est presque paralisee pendant plusieurs secondes
* avec l'Adaptec: le meme test me rend la main bcp - vite, mais je n'observe pas le moindre ralentissement ... les benchs dependent bcp de la qualite des drivers ...

J'ai également une Tekram et une Adaptec, et les 2 marchent très bien. La Tekram est une DC-390 (Ultra SCSI, à savoir 20 Mo/s max), et l'Adaptec est une 2940UW (Ultra Wide soit 40 Mo/s max). A mon avis, pas la peine d'acheter une Adaptec, on a aussi bien avec Tekram pour beaucoup moins cher (c'est ce qui motive mon commentaire).

<ma vie>
Initialement j'ai pris une Tekram, quand j'ai acheté mon premier PC fin 1998 pour me mettre à Linux. Je voulais du SCSI même si c'était plus cher que de l'IDE, car l'IDE c'était du bête matos de Windowsien (venant de l'Amiga je connaissais bien les qualités du SCSI). La Tekram était bien supportée dès le début (SuSE 5.3). D'ailleurs le type qui maintenait activement le driver était Kurt Garloff (il a été sponsorisé par SuSE par la suite), à présent un peu connu car il bosse sur le kernel. J'ai eu jusqu'à 5 périphériques sur la carte : 2 disques durs, 1 CD-ROM, 1 graveur et 1 scanner.

Voulant monter un peu en gamme j'ai acheté 2 ans plus tard l'Adaptec avec un disque UltraWide. J'ai eu le plaisir de passer de 12-13 Mo/s à 20-21 Mo/s. Depuis j'ai mis mon lecteur et graveur sur la carte, et j'ai gardé la Tekram pour le scanner, dont je me sers peu. Et surtout, pour des raisons de silence, j'ai viré mes 2 disques SCSI et je les ai remplacé par un IDE ultra-silencieux, un Seagate Barracuda IV. Tant pis pour les perfs, pour ce que je fais de mon PC.
</ma vie>

Une URL intéressante pour les comparaisons entre disques, que ce soient les performances (haut ou bas niveau), la température ou le bruit : http://www.storagereview.com/php/benchmark/bench_sort.php(...) .

Il fait son test sur un répertoire maildir contenant 50 000 mails. OK.
Mais quel est l'état de fragmentation des disques ?

C'est une bonne question mais il me semble que dans les commentaires du test, l'auteur (Gerard Beekmans) répond à ce genre de question. Par exemple ici :

Re:fragmentation is the cause, not SCSI vs IDE
by Gerard Beekmans (161) on Monday October 20, @08:05PM

I took steps to make the fragmentation as similar as possible. As I wrote elsewhere in a comment, I copied the files prior to testing so I wouldn't have the fragmentation on one drive and everything nicely sequential on the other. I also rebooted between tests as far as I could (I didn't reboot the server for obvious reasons but I ran the test on both its harddrives which are identical in specs).

Personnellement, je n'ai guère été surpris des résultats (SCSI > IDE). Le firmware des disques SCSI n'est pas le même que celui des disques IDE et a une influence mesurable sur les performances. Le site AnandTech l'avait mis en évidence sur des tests de base de données, en testant un IDE SATA performant par rapport à un SCSI du même type.
A noter aussi le TCQ (Tagged Command Queuing) qui permet aussi d'accélérer les opérations : le disque réordonne les accès dans la mesure du possible pour minimiser les mouvements de la tête.

Sur ma machine perso, je suis passé d'un disque SCSI IBM 9 Go à un IDE Seagate Barracuda IV de 40 Go (tous les 2 à 7200 tr/min), et bien que ma carte mère MSI ait un contrôleur IDE avec DMA, l'IDE continue à prendre plus de CPU que le SCSI. En SCSI la machine était toujours fluide, en IDE on arrive à ressentir les accès disques intenses.

Par contre, la remarque de l'auteur comme quoi avec un contrôleur Ultra320 et PCI 64 bits ça aurait été plus vite qu'avec son contrôleur Ultra160 et PCI 32 bits, c'est du pipeau :
Note that the controller is an Ultra160 and is a 64-bit card put into 32-bit PCI slot. The drive itself is an Ultra320. The speed increase would be higher if I were to purchase an Ultra320 controller with a motherboard that supports 64-bit PCI slots.
D'une part le PCI 32 bits est capable (théoriquement) de 133 Mo/s, ce n'est pas ça qui va brider un disque à 20-40 Mo/s. Ensuite, avec du SCSI Ultra2-Wide (80 Mo/s), c'est déjà le disque qui bride les performances, pas l'interface.

Dans ce cas-là, ça s'écrit voire...

Tout à fait, ce n'est pas du pinaillage car le sens est bien différent, il ne s'agit pas du verbe "voir". (de plus en plus de gens font la faute il me semble)

En fait le modérateur a laissé une faute, car "voire identiques parfois" est un pléonasme (comme "voire même"), il suffit de dire "voire identiques", le "voire" étant là pour suggérer une possibilité ou une potentialité.

Ouais, heureusement qu'elle est mignonne :-)

C'est possible mais elle n'a pas le sens de l'esthétique, avec les photos déformées par le format carré (alors que c'est du 4/3 vu que ça a l'air de venir d'une webcam).

Steed102/Clem tu devrais mettre les photos dans leur proportion d'origine. En l'occurence, tu as mis dans ton code HTML : {img src="images/Image 44.jpg" width="200" height="200"} alors que les vraies dimensions de l'image sont 320x240 (j'ai vu ça avec "show image", ça vient bien d'une webcam). Tu n'as pas besoin de préciser "width" et "height" cela dit.

A part ça, arrange-toi pour que ton site soit léger et évite un peu les gadgets (trucs qui clignote ou qui défilent). On peut faire sobre et joli, et lisible.

Merci de corriger : s/codées/encodées/

Pfff, Daemo0on tu es vraiment vicieux... et plus têtu que moi on dirait !

Je précise pour nos lecteurs : "encoder" est un affreux barbarisme (anglicisme dû à "to encode", ce n'est pas difficile à voir), certes toléré mais franchement à proscrire, tout comme on dit chiffrer et non "encrypter". Le terme correct est "coder" comme dans "message codé", "brin d'ADN codant", "codage préfixe" (la compression de Huffman est un codage préfixe), "codec" (CODeur/DECodeur), etc..

PS: merci à Oumph d'avoir fait la correction.