Richard Van Den Boom a écrit 388 commentaires

> Ah ? Là, c'est des fontes vectorielles, donc faite pour l'impression.

Je ne comprends pas ce que tu veux dire. Aussi bien les fontes TrueType que les fontes Type 1 sont vectorielles et sont utilisées depuis belle lurette pour l'affichage, en plus de l'impression. Sur mon KDE, toutes mes fontes par défaut sont ainsi en Garamond Type 1.
En l'occurrence, il s'agit surtout, d'après ce que j'ai compris, d'un jeu de caractères étudié pour s'afficher correctement à l'écran et y être bien lisible, ce qui implique surement des contraintes particulières d'empattement, de proportions, etc.

Richard Van Den Boom

Non car pour se linker sur une librairie GPL, le programme doit aussi être GPL, y compris ton "champignon". C'est pour éviter ce problème, je pense, qui devait empêcher entre autres les programmes distribués sous autres licenses libres d'utiliser des librairies GPL, que la LGPL (Library GPL) a été créée. Donc tu peux compiler XFree avec la glibc qui est sous LGPL, mais tu n'aurais pas le droit avec une librairie C sous license GPL (vu que XFree est sous X11). Corrigez-moi si je me trompe. Cordialement,

Ce qui est intéressant, c'est qu'ils ont apparemment écrit une librairie permettant de s'affranchir (au moins pour KHTML et KJS) de QT et de KDE. Serait-elle assez large pour permettre d'autres ports d'applis KDE vers des systèmes équipés ni de QT ni de KDE?
Et du coup, pourquoi ne pas concevoir qu'Apple porte beaucoup plus d'applis KDE dans le futur, haut hasard KOffice? Ne sont-ils pas soit disant en train de développer une suite légère et performante censée à terme concurrencer Office sur leur plateforme? Et plutôt que de se casser la tête à repartir à zéro, pourquoi ne pas plutot prendre ces applis KDE toutes faites et cohérentes, quitte à les améliorer un peu?
Moi qui pourtant ai une vrai dent contre Apple, s'ils se décident à procéder ainsi en contribuant en retour à l'amélioration de KDE, je serais alors prêts à revoir mon opinion sur eux et à leur accorder un statut similaire à IBM (ce qui veut dire ce que ca veut dire...).

Cordialement,

C'est d'autant plus étrange comme discussion que bon nombre de librairies du libre sont distribuées en LGPL et non en GPL. Or, la différence principale est justement que les codes propriétaires peuvent se linker en dynamique dessus sans pour autant révéler leur source.
Donc, je ne vois pas bien l'intérêt de son propos. Chaque développeur de librairie libre a le choix d'imposer son utilisation par des logiciels libres uniquement ou par tout le monde. Il est tout de même la seule personne à pouvoir faire ce choix, non?

Cordialement,

Contrairement à l'Open Source, une boite, ca a des deadlines. Si ca prend 6 mois de créer un navigateur stable avec un moteur qui rend bien 99% des sites et supporte les plug-ins Netscape, tandis qu'avec un autre qui rend bien 100% des sites, ca prend deux ans, le premier sera choisi.
Le mail initial auquel tu as réagi était un peu trollesque, j'en conviens (et pourtant je préfère de loin KDE) mais il est peut-être plus simple et plus réaliste d'admettre qu'il peut y avoir des raisons techniques, en plus de celle que tu invoques qui est envisageable, expliquant le choix d'Apple.

Cordialement,

C'est déjà supporté dans KDE 3.1. Est-ce plus lourd maintenant, je ne sais pas.
Cela dit, il n'y a pas que la lourdeur en tant que code, mais la facilié d'implémenter un navigateur utilisant ce moteur. J'ai idée que c'est plus simple avec KHTML (qui est un module conçu pour être appelé par différentes applis dans KDE très facilement, par exemple dans KMail) qu'avec gecko et que c'est pour cela qu'il a été déjà deux fois préféré.

Cordialement,

Avec la RC de KDE 3.1, je n'utilise pratiquement plus que Konqueror. Je dois avoir un site tous les 3 mois qui ne passe pas. Il y a bien de temps en temps encore quelques petits bugs d'affichage mais la liste se réduit très vite.
Alors pourquoi autant de fanatisme? KHTML est peut-être très simple pour un programeur à implémenter dans un navigateur, ce qui explique son choix. Je rappelle que le développeur d'AtheOS avait lui aussi choisi Konqueror et KHTML comme base de son navigateur, pas Gecko, c'est peut-être qu'il y a de bonne raison à cela et que développer un navigateur à partir de ce module est d'une simplicité déroutante.
Vous devriez vous réjouir qu'Apple contribue enfin au libre en apportant un bon nombre de correctifs à un projet open source, plutôt que de vous enfermer une fois de plus dans une querelle partisane puérile. J'avoue que cela m'étonne d'eux.

Cordialement,

Mouais, en attendant, je préfèrerais que les développeurs de film-gimp se concentrent sur la convergence de ce projet avec gimp-1.2.3 plutot que de nous faire un portage pourri sur une plateforme que personne n'utilise dans le milieu du cinoche ou de l'animation.
Bon, personne, c'est un peu exagéré mais disons que c'est une plateforme ultraminoritaire sur ce marché comparé aux PC et aux Unix, et film-gimp serait beaucoup plus attrayant avec le support de certains outils disponibles en 1.2.3.

Cordialement,

PS : J'ai un dégoût d'Apple qui est certainement pour beaucoup dans mon commentaire peu objectif. :-)

A comparer au 270 euros d'un AXP 2000+ et d'une carte Asustek nForce2.
A ce prix là, mieux vaut encore une carte mère Socket 370 et un processeur VIA C3 933MHz. Ca, je sais que c'est compatible avec tout et ca fonctionne sans problème sans ventilateur, avec juste un radiateur passif. Et ca me coutera 4 fois moins cher pour des performances similaires.
Dommage.

Cordialement,

>Euh, pour une techno donné le temps de parcoure d'une porte est fixe. Tu peux mettre >plein de portes en parrallèle (ipc monte), moins de porte entre 2 registres (pipeline, >frequence monte), ou refaire le routage (moins de temps perdu dans les fils, la fréquence >monte).
En quoi est-ce contradictoire avec ce que j'ai dit? L'introduction des architectures OoO s'est généralement faites à même fréquence et même technologie de gravure que l'architecture In-Order. Cela correspond à ton premier cas.
A l'époque, elle représentait le meilleur rapport changements-gains, c'est pourquoi elles ont été appliquées. Les autres techniques sont également appliquables mais ont leur limitations. En générale, la manière la plus simple et la moins couteuse est d'affiner la gravure, ce qui permet souvent au passage d'autres améliorations, surtout au niveau du cache et la baisse de consommation thermique. C'est généralement ce qui est arrivé avec le PII puis PIII, le P4 et l'Athlon original. Pour l'Athlon XP, le changement de finesse de gravure n'a pas vraiment suffit à faire monter la fréquence de façon significative, d'où la nécessité de refaire l'architecture, avec Hammer.
La finesse des outils de gravure a un impact considérable sur la fréquence des processeurs, la longueur des traces, la taille du cache, etc. Le fait que l'on ait diviser la finesse de gravure par 3 en 5 ans montre l'impact énorme qu'elle a.

Cordialement,

Et c'est quoi le prix de la bête?
Parceque, pour avoir les perfos d'un Duron 800Mhz, ca a intéret à être bon marché. Surtout quand tu vois le prix maintenant d'un Athlon XP 1.5Ghz. :-)

Cela dit, ca doit être bien silencieux, bien pour une set-top.

Cordialement,

>Yep parce que les processeurs RISC n'ayant pas encore les poids des années et de la >compatibilité n'en avait pas (encore) besoin.
Je ne sais pas si on pas si c'est trop ça. Ce n'est pas tant une raison de compatibilité que de vouloir augmenter l'IPC du processeur à même fréquence. Augmenter la fréquence pose parfois des problèmes, car elle nécessite des outils de gravure de plus en plus affinés, qui ne sont pas forcément disponibles. C'est aussi ce qu'à rencontré DEC avec le 21164. Donc, pour augmenter malgré tous les performances, on augmente l'IPC. Et le OoO permet en partie d'éviter les états d'attente des processeurs superscalaires en cas d'instructions indépendantes.
Ainsi le PPro a augmenté sensiblement les performances du Pentium à même fréquence, en restant (si je me souviens bien) en gravure 0.35µ, tandis que l'Alpha 21264 a doublé celle du 21164 à même fréquence et même finesse de gravure (0.25µ là encore si je me souviens bien).

> RISC/CISC qualifie le jeu d'instruction pas leur implémentation
Autant que je sache, c'est exact.

Cordialement,

L'exécution d'instructions dans le désordre a été introduite par le Pentium Pro dans le monde CISC, tandis qu'elle n'est apparue dans le monde RISC que bien plus tard, par exemple avec l'Alpha 21264 ou l'UltraSparc III.
Comme quoi, des innovations, il y en a eu dans les deux sens et les deux architectures ont bénéficié des avancées de l'autre.
Il faut aussi préciser que, au delà des jeux d'instructions proprement dits, les processeurs actuels du monde x86 sont des RISCs qui se cachent : en effet, tous incorporent en réalité une étape de décodage des instructions x86 en micro-instructions de type RISC, plus faciles à éxécuter dans le désordre.
Cet discussion CISC contre RISC n'a plus aucun sens de nos jours. Elle n'incorpore même pas les jeux d'instruction VLIW qui commencent à apparaitre avec les processeurs de Transmeta ou l'Itanium d'Intel.

Cordialement,

Assez douteux, puisque le P4 et l'AXP ont parmi les meilleurs performances, sinon les meilleurs performances en SpecINT. Les seuls éventuels concurrents sont les Power d'IBM, à un prix défiant toute concurrence (vers le haut...:-)).
La vérité, c'est qu'une échelle de performance, c'est assez compliqué à trouver, surtout quand il s'agit de comparer des architectures très différentes. Il n'y a pas de formule magique, il faut se faire une idée en comparant les architectures sur les applications que l'on compte utiliser.
Personnellement, je vais sur le site www.aceshardware.com, ils y font peu de revues, mais bien documentées et les gars savent ce qu'ils testent, contrairement à la grande majorité des sites de matériel. Le forum est aussi assez intéressant car il y a plusieurs ingénieurs et informaticiens visiblement compétents qui contribuent. Evidemment, comme dans tout forum, il y a toujours des excités un peu fanatiques qui cherchent à défendre telle ou telle marque, mais globalement, on peut avoir des analyses et des informations techniques d'assez haut niveau.

Cordialement,

C'est particulièrement sensible pour KDE. Je tourne sous Slackware et ai upgradé en Current pour tester les releases candidates de KDE3.1 compilées avec GCC 3.2. Ben, y'a une nette différence. Non seulement il a de la gueule mais est maintenant bien rapide et stable. Que du bon.

Cordialement,

Tu proposes une alternative à une personne donnée, par rapport à ce dont elle a l'habitude, pas en général. Tu ne peux pas espérer que quelqu'un qui a pris l'habitude de travailler sous Word va considérer TeX ou même DocBook comme une "alternative".
Les systèmes comme TeX ou DocBook sont parfaits pour générer des documents techniques pouvant être fournis sous plusieurs media. Ils ne sont pas adaptés à la réalisation de mises en page complexes et avec images, tranparences comme des slides de présentation commerciale ou des magazines. Il y a de bonnes raisons qui poussent les boites de PAO à utiliser des soft WYSIWYG, comme il y a de bonnes raisons que les publications techniques utilisent plutôt les outils de type TeX ou DocBook.
Ce ne sont pas des "alternatives" mais des outils différents, ciblant des travaux différents en général, même si un petit overlap existe.

Cordialement,

C'est ma galère permanente avec OpenOffice.
Tiens actuellement, il ne prend plus en compte le circonflexe. Si je tape ^-i ou ^-e, j'ai rien, pas de caractère. Je démarre Kword, je tape ^-e et j'ai ê.
Va comprendre, Charles.
En bref, OpenOffice, c'est pas mal, mais je pense migrer peu à peu vers KOffice.

Cordialement,

Quand tu installes Office, il te met dans ton répertoire Démérrage du menu Démarrer une petite icone "Démarrage rapide". Elle fait très exactement ce que l'on t'as décrit.
Ce n'est pas fourni avec Windows, bien sur, mais c'est installé automatiquement avec MS Office.
Moi, j'attends toujours Smartsuite sous Linux, même oayant. En attendant, KOffice a fait de gros progrès et est bien plus léger que OpenOffice même si toutes les fonctionnalités n'y sont pas encore. Normal, ses librairies sont déjà chargées :-).
J'ai bien aimé, d'ailleurs, quand Kword s'est encapsulé dans Konqueror la première fois que j'ai téléchargé un fichier .doc du net. Bon, ca a planté Konqueror, mais dans le principe, j'ai trouvé ca vraiment chouette.

Cordialement,

Rien n'empêche bien sur d'en parler, mais n'oublions pas qu'il s'agit de la même chose que de parler de Cygwin ou de Xfree86 sous Windows. Des outils libres, soit, mais ca ne fait pas de l'OS un système libre pour autant.
Cessons ce petit discours glamour qui voudrait que Mac soit plus proche du libre que MS : Apple et MS font le même combat et il n'y a aucune raison d'enhancer l'un ici en décriant l'autre.

Cordialement,

J'ai une carte mère nForce et un GeForce4 MX440, ca marche impeccable sous Linux et contrairement à ce que j'ai pu lire plus haut, je n'ai eu aucun souci de stabilité ou de performance. Il est vrai qu'il faut autoriser le kernel à supporter les pilotes non GPL mais c'est par défaut dans les dernières distributions. J'ai un peu du bricoler ma Slack mais maintenant tout fonctionne bien.
Qui dit nForce dit AMD, pas cher et très bien. Eviter de mettre un gros proc et plutot privilégier les 256Mo de Ram. Mandrake est bien pour le grand publique. Quant à la Red Hat 8, je ne suis pas vraiment convaincu. Rien de bien nouveau dans cette distribution finalement, pour le bruit que cette sortie a fait.
5000Fr sans écran, c'est trop. Il faut descendre vers les 500 euros.

Cordialement,

Le choix entre les deux est comme bien souvent une affaire de gout et de couleurs. Si tu regardes les autres commentaires, tu en vois certains qui te disent que mplayer est plus tolérant tandis que d'autres te disent le contraire.
En pratique, ce qui est vraiment important, c'est que l'un ou l'autre lisent correctement les fichiers et media que tu veux visualiser. Si tout va bien, ne change rien. Si un fichier ne passe pas, essaye l'autre.
Personnellement, j'utilise Xine. Il lit tous mes fichiers et mes DVD sans problèmes, je n'ai aucun des problèmes de ressources et de lenteur que certains lui attribuent, et en plus j'aime bien lire leur ML développement car il y a vraiment un bon esprit (ca n'a rien a voir avec le programme lui-même mais bon...). Je trouve sympa d'ailleurs que les dev de Xine et de Mplayer interviennent dans les deux ML respectives : ca fait avancer les deux projets.
Quant à l'intégration de Xine dans d'autres projets, comme KDE, j'ai l'impression que c'est du à sa structure séparant clairement librairies-interface, ce qui rend l'utilisation des librairies dans d'autres logiciels très simple, à commencer par les différentes interfaces et plugins existants.
Le fait de pouvoir encoder avec mplayer est certainement un plus. D'après la ML Xine, l'un de leurs futurs développements sera d'étendre les lib-xine pour pouvoir faire de même, et en particulier pour en faire une base complète pour tout logiciel de manipulation video.

Cordialement,

C'est assez discutable tout ca. L'utilisation du mot 'Internet' implique en général l'utilisation du réseau mondial. On ne dit pas (du moins je n'ai jamais entendu parler) 'Internent' pour un réseau local, on dit justement réseau local. Quant aux sites qui ne doivent être accédés que par un nombre restreint d'utilisateurs, on parle d''Intranet' pour un réseau interne et d'Extranet' pour un réseau distant à accès réservé.
Donc pour moi, Internet représente un bien un réseau unique et peut en conséquence être considéré comme son nom propre, se passant finalement bien de ce "l'".

Cordialement,

Tout à fait. Une license Shake représenterait à elle seule 25% du budget prévisionnel. Complètement ridicule pour nous. Donc en effet, je lorgne vers le LL. Je vais faire quelques essais plus poussé avec Cinerella. Je regarde Kino aussi qui a l'air assez dynamique, même si pour le moment en matière d'édition, c'est extrêmement limité.
A ce propos, sur la mailing list de Xine, ils ont laissé entendre qu'ils comptaient à terme orienter leur projet de façon à proposer un front-end d'édition vidéo. Je trouve ça assez intéressant comme principe : ils fournissent toute l'architecture pour le traitement des flux audio et vidéo, comme celà n'importe quel développeur peut ensuite développer une interface adaptée (un peu comme actuellement leur GUI). Ca me semble un très bon principe et j'espère que cette optique du projet va se faire rapidement. Du coup, il y aura toujours des gars pour développer un front-end à la fois pour KDE et Gnome, et tout le monde est content.

Cordialement,

RVDB

Un film d'animation demande de plus en plus une postprod similaire à un film normal. Il y a de nombreux effets que tu ne peux automatiser que par un logiciel qui dépasse le simple logiciel de montage : profondeur de champ automatisée, utilisation de moteur de particules, etc.
Il y a plein de chouettes choses à faire avec les compositeurs informatiques, même sur un dessin animé, et ce serait dommage de s'en passer.
D'autre part, je ne fait peut-être pas du HDTV mais pour une sortie pellicule, il faut au moins travailler en 2K, ce qui est pratiquement la même chose que du HDTV, en non entrelacé. De plus, j'ai enfin réussi à compiler Cinerella : outre que je n'ai pas pour le moment trouvé comment charger des images fixes (il n'a l'air de supporter en entrée que des fichiers vidéo), il m'a semblé extrêmement proche de Premiere, ce qui n'est que le strict minimum pour un travail sérieux en animation. Ce que je voudrais, c'est plus quelque chose du genre After Effects ou (rêvons) Shake. Il y a bien Jahshaka mais le développement semble lent et ils mettent un temps fou à sortir une version sous QT3.

Pour ce qui est des films, évidemment, on a de grande chance d'être déçu si on compare les nouvelles sorties au cinéma avec les films de Miyazaki. En général, elles ne pourront faire que pale figure. Celà dit, Shrek était vraiment bien à tous les points de vue, et ce n'est guère étonnant qu'ils soient allés jusqu'à mettre son nom sur l'affiche de Spirit : c'est leur meilleure référence. Malheureusement, pas besoin d'être sorcier pour voir que le nouveau n'est pas à l'avenant de l'ancien.

Cordialement,

Richard Van Den Boom

J'ai testé, c'est pas trop mal fait mais cela reste très rudimentaire : c'est plutôt orienté images GIF animée sur le web et ça n'est même pas très pratique pour faire les dessins eux-mêmes. Celà facilite par le contre le traitement en chaines sur un grand nombre d'images.
Enfin bref, c'est un ajout utile mais celà ne remplace pas un logiciel de montage ou de compositing.

Cordialement,

Richard Van Den Boom