gabuzo a écrit 236 commentaires

Le film 35mm permet de projeter des images plus grandes, plus nettes et plus lumineuses que les vidéo-projecteurs. De plus, toutes les salles de cinéma sont équipées de projecteurs 35mm.

C'est vrai & faux à la fois. Dans l'absolu oui mais dans la pratique, les transferts des images en 35mm se font probablement dans une résolution inférieure à la résolution maximum du 35mm ; résolution pour laquelle il existe des projecteurs numériques. Le point le plus important ici est bien sûr l'universalité du 35mm qui peut être projeté dans toutes les salles de cinéma du monde.

Pour avoir un doublage qui soit à la hauteur de l'original il faudra refaire l'animation des visages, car celle ci est basée sur les voix et enregistrements vidéos des acteurs. (et il faut aussi trouver des bons acteurs et un bon studio) Bref, c'est pas aussi facile qu'on ne le pense !

Pour info les doublages de films d'animations 3D commerciaux se font sans toucher l'animation VO d'un poil sans que cela semble géner les amateurs de versions doublées ça ne me paraît donc pas indispensable.

D'ailleurs si un doublage se faisait de cette manière on changerait probablement plus que l'animation des visages sachant comme tu le dis que les animateurs se basent, entre autre, sur les enregistrements vidéo des acteurs voix. En passant, cela n'a rien de vraiment novateur puisqu'au début du cinéma parlant la première idées des producteurs de l'époque était le tournage multilingue des films. Le procédé a bien sûr été abandonné rapidement pour des raisons de coût le dernier exemple me venant à l'esprit étant « Les demoiselles de Rocheford » pour lequel ont été tourné une version anglaise & une version française.

[...] il ne faut pas regarder le code généré [...]

Sans que ce soit propre à Netbeans c'est un peu ce qui me gêne avec les GUI Builders : on arrive à faire rapidement quelque chose d'agréable mais c'est au final très difficile à maintenir et la réutilisabilité entre deux composants graphiques similaires est proche de 0 car tout est fait directement à partir des objet Swing (ou autre) sans création d'objets de plus haut niveau pour les fonctionnalités communes.

Même si le format de fichier de Word était public à 100% cela ne résoudrait pas à 100% les problèmes d'interopérabilité entre Word & OOo.

Par exemple, la manière dont OOo & Word gère la création automatique des tables des matières & la numérotation des chapitre est complètement différente : de mémoire dans Word c'est dans le style du paragraphe que l'on inclus la numérotation & le niveau du paragraphe associé alors que dans OOo il y a une notion de plan dans laquelle on place des style de paragraphes qui ne porte pas de numérotation. Rien que sur un tel exemple le travail pour passer d'une notion à l'autre est très important.

Si l'on y ajoute aussi les habitudes des utilisateurs pour contourner les bugs de l'un & l'autre je doute qu'il soit vraiment possible d'arriver à une opérabilité parfaite entre les deux logiciels.

Plus serieusement, meme si l'idee de grossir, de fusionner plusieurs equipes afin d'avoir un produit plus performant plus rapidement a l'air realiste, comment est ce que Mandriva finance tout cela ??

Tout bêtement par échange d'actions (qui a dit monnaie de singe).

On peut faire un proc meilleur qu'un intel à fréquence égale mais ça va pas être de la tarte pour monter aussi haut en fréquence que les dits intel

Vrai mais sachant que le marché des PPC pour le desktop est très réduit IBM n'a en aucun cas les même moyens que ceux que Intel ou AMD peut mettre pour faire évoluer un processeur.

ah bon? comment? si ca installe windows, ca peut installer linux..

Par exemple avec un composant spécifique et en ne fournissant le driver que pour Windows.

Il y a quelques années, le changement 68k -> PPC avait fourni un prétexte pour pousser la base installée à renouveler son parc (qui se souvient encore des Mac Quadra ?).

Oui pousser est bien le mot car Apple avait, par miracle des délais de livraison très importants sur les Mac 68040 (de l'ordre d'un mois) alors que les Mac PPC étaient livrés en quelques jours. Sachant que les applis qui n'avaient pas été compilées pour PPC se traînaient lamentablement sur les PowerMac (Apple avait déjà eu l'idée de fat binaries à l'époque mais certains applis n'ont jamais été adaptées au PPC) les utilisateurs potentiels avait le choix entre attendre une livraison, travailler avec des applis se traînant ou changer complètement d'optique en passant à du Wintel.

La souris à un bouton, le boitier super design, la carte graphique spécifique avec son connecteur spécifique vers le moniteur, le système de ventilation super silencieux des macs actuels et et surtout la pomme sur la machine qui lui permet d'être vendue dans un rayon à part à la Fnac.

A la fin de sa conférence, Jobs a déclaré "ce qui importe chez Apple, c'est le logiciel", pas le matos...

Sauf que c'est ce même Steve Jobs qui vers 1998 a complètement changé la direction prise par Apple qui s'orientait nettement vers le logiciel en autorisant, par exemple, la création de clones de Macintosh. C'est d'ailleurs suite à cette décision que Motorola a arrêté le developpement des processeurs desktop/server pour se consacré à l'embarqué. Ensuite si j'en crois l'un des commentaires de cette page, MacOSX86 ne s'installera pas sur un PC ordinaire ce qui est en totale contradiction avec cette phrase (même si le matos en question est une carte PCI à plein de brouzoufs avec dessus un chip ®© patent pending Apple).

Sinon sachant que Apple développe depuis 5 ans MacOSX sur PPC & x86 on peut penser que Steve Jobs savait bien qu'il avait scié la branche sur laquelle se trouve Apple & qu'il faudrait rapidement trouver un solution de rechange.

C'est vrai qu'il est ridiculement facile de passer outre les systèmes de protection anti-copie mais faire ce que tu fais (acheter des disques protégés contre la copie puis les déprotéger pour pouvoir les utiliser sans contrainte) est une très mauvaise solution.

Étant donné que l'action judiciaire n'a, pour l'instant, pas donné de résultat la seule manière qui reste est de frapper au portefeuille en refusant d'acheter les disques protégés, en les rapportant au magasin comme défectueux, etc. Acheter un disque protégé c'est contribuer à la généralisation de ces systèmes car cela permet de dire que « les ventes prouvent que les systèmes anti-copie ne sont pas rejetés par les clients ». Une généralisation des systèmes actuels n'est probablement pas un problème pour un informaticien chevronné mais je pense que pour 95% de la population cela serait catastrophique.

Enfin si les systèmes actuels sont risibles il n'est pas du tout évident que cela soit toujours le cas surtout si les majors arrivent à faire passer toutes les lois qu'elles ont en magasin (obligation d'intégrer des systèmes anti copie dans les composants, etc.).

Sans trop trop troller, je ne suis pas sûr que lancer un nouveau SCM libre soit une bonne solution pour améliorer la maturité des SCM libres. Quelque soit les qualités de git, il va se passe énormément de temps entre la 1.0 en ligne de commande & l'apparition de GUI ou de plugins pour l'intégration avec les outils de développement. Il suffit de regarder des outils comme Subversion, arch ou SVK pour voir le temps qu'il faut.

Mais bon, a-t-on vraiment besoin du support de la toute dernière
Gforce 1234124+ sur un PDP10?
xorg est-il vraiment nécessaire sur ce genre d'archi?

Probablement vrai mais est-ce que ça ne revient pas à déplacer le problème. En disant tout le monde sur Xfree 4 on simplifie aussi l'intégration des autres applications qui seront assurées de tourner sur XFree 4.

Ils aurais pus trouver un truc plus sympas au lieu de faire "copuler" leur 2 noms.... Mais c'est vrai qu'un nom peur couter trés cher de nos jours.

Surtout que payer une boîte de comm' pour trouver un nom ne garantie pas le résultat. Par exemple la fusion des banques d'investissement du Crédit Agricole (CA) & du Crédit Lyonnais a donné CALyon. Au moins si Mandrake/Conectiva a réussi à trouver Mandriva en 10 minutes sur un coin de table c'est une bonne chose & c'est souhaitable sachant que la boîte n'est pas passé loin de la fermeture. Autre point Mandrake est toujours en litige avec les ayant-droits de Mandrake la magicien ce qui donne un argument de plus pour changer le nom.

Bah surtout que l'expert C++ qui travaille en SSII, sans héritage il risque pas de devenir riche ;*)

À mon avis tu n'as pas besoin de préciser l'expert C++, ni sans héritage pour arriver à : celui qui travaille en SSII ne risque pas de devenir riche.

Ok je sors.

Xprint je ne sais pÔ mais pour CUPS, Gutenprint est sélectionné comme driver lors de la déclaration de l'imprimante. C'est donc Gutenprint qui est chargé de la phase phase finale de l'impression.

Sincèrement je ne pense pas. Les SSII apportent de la flexibilité aux entreprise en leur donnant de la main d'oeuvre facile à virer mais permettent aussi de déléguer des tâches coûteuse comme l'embauche (récupération de CV, sélection, entretien avec les candidats, négociation, etc.) ou la gestion de la carrière des collaborateurs (évolution de poste, formations, etc.) à des sociétés tierces. Comme l'a fait remarqué très justement quelqu'un le fait d'externaliser la main d'oeuvre permet aussi de mettre en avant des réductions de personnel plus ou moins fictive vis à vis des actionnaires ou de faire des effets d'annonce en virant des bataillons d'employés que l'on reprend via des sous-traitants.

Dans des pays comme le Royaume-Unis ou les États-Unis où il est très très facile de virer quelqu'un les société on malgré tout recours massivement aux sociétés de service. C'est donc probablement parce qu'il n'y a pas que l'aspect tu m'plais pas, j'te vire qui motive les entreprise à recourir aux SSII.

Dans ce cas, à quoi servent les ssii?

À pas mal de choses :

- à réduire la taille du département ressources humaines en déléguant aux SSII les coûteuses phases de récupération des CV et de première sélection des candidats potentiels ;
- à réduire le nombre d'interlocteurs via des short lists permettant de ne garder que quelques grosses SSII (qui vont éventuellement sous-traiter à des indépendants) ;
- à rester entre gens de bonne compagnie qui peuvent aller golfer ensemble & fixer les tarifs des prestations au club house sans avoir besoin d'inviter une horde d'emm^W d'indépendants.

Le "reverse engineering" est illégal, sauf s'il est fait dans un but d'interopérabilité.

Je ne pense pas que ce soit le cas en France. Ce n'était d'ailleurs pas le cas aux USA avant l'entrée en vigueur du trop célèbre DMCA.

Est ce legal d'interdire d'installer un logiciel sur plusieurs ordinateurs ?

Oui clairement car le fait d'ouvrir ton logiciel revient à accepter les clauses du contrat de la license (on laisse de côté les cas où il faut ouvrir l'emballage avant de pouvoir lire la license, etc.).

La seule solution serait qu'un tribunal déclare cette clause comme abusive.

Pour le coté "rapace" d'Adobe, oui, tout a fait d'accord.

Sans trop trop prendre la défense d'Adobe j'ai lu en entier la license de logiciels Adobe il y a quelques années de cela et ce qui m'avait frappé était que contrairement à d'autres fabricants de logiciels, Adobe avait une license intelligente. Je pense en particulier au fait qu'il était explicitement autorisé de faire plusieurs installations d'un logiciel, par exemple au bureau et à la maison/sur un portable sous réserve qu'il n'y ait pas deux utilisateurs simultanés.

C'est bête mais quand je regarde voit Microsoft (mais ils ne sont pas les seuls) qui cherche attacher Windows au hardware avec l'activation sous XP je me dis qu'Adobe a une politique commerciale qui prend moins les utilisateurs pour des pigeons que les autres. À cela j'ajouterai qu'Adobe a créer des langages/formats comme PostScript ou PDF avec là aussi des licenses utilisables par des concurrents.

Alors que le 16bit par canal n'est utile que pour un re-transfert sur pelloche ou impression HD. Dés lors, ça ne concerne pas tout le monde.

Non ce n'est pas utile uniquement pour un re-transfert sur pelloche ou une impression HD. Pour de bêtes photos de vacances complètement sous exposées à cause de la neige qui a aveuglée le système d'exposition de l'appareil numérique. Si Gimp était capable de traiter directement l'image en 16bits par canal récupérer une image correcte pour un bête affichage à l'écran aurait été un jeu d'enfant. Comme Gimp ne gère "que" 8 bits par canal cette opération n'est pas faisable directement. Il faut soit utiliser film-gimp (qui est, à mon avis, très en retard sur gimp 2) soit travailler les paramètres du convertisseur 16bits->8bits. C'est pour pallier à ce manque que l'auteur du plugin ufraw a été obliger de dupliquer une partie des fonctionnalité de gimp au sein d'un loader.

le "margoulin" (j'aime bien ce terme :) ) qui lit ça(*) aura directement comme réaction: Gimp sux

Ça n'était pas mon but. Pour info mon commentaire original était juste une nuance sur l'architecture de Gimp. En gros les développeurs de Gimp ont fait un travail énorme pour rendre gimp plus modulaire, plus propre, etc. mais certains choix d'architecture fait à l'origine, comme le codage de couleurs sur 8 bits par canal, continuent de poser des problèmes.

Donc l'idéal est de calculer le plus précisément possible, même si on se limite à une certaine précision à l'affichage (parce que l'oeil humain ne voit pas plus précisément). Si on doit tronquer à un moment, il faudrait ne le faire qu'à l'étape finale.

C'est bien ça ?

Tout à fait en sachant qu'en pratique il est très très difficile de connaître l'étape finale. Par exemple après avoir appliquer un filtre on peut très bien avoir besoin d'en appliquer un autre d'où la nécessité d'un stockage interne et d'une sauvegarde en plus que 8 bits.

Par curiosité j'aimerai bien savoir pour quels type de travaux les 16bits par canaux te sont nécessaires ?

De la retouche photo. Dans le cas d'une photo sur ou sous exposée, travailler en 16 bits permet de corriger l'exposition en évitant des perdre tous les détails dans les ombres & les lumières. Autre exemple: prenez une photos sur le web (je viens de faire le test avec une image de Libération) ouvrez la fenêtre d'histogramme: vous verrez probablement une courbe continue. Maintenant faites une égalisation (dans calques/couleurs/auto) & regardez la gueule de l'histogramme: de nombreux trous sont apparus. De ce fait on utilise plus la totalité des 16 millions de couleurs disponibles. Travailler en 16 bits aurait permis de minimiser cet effet.

Tu peux argumenter ? Le code du gimp est un modèle du genre : très bien structuré, bonne utilisation des objets, séparation complète des fonctionnalités et de l'interface. Je ne vois pas grand chose de particulièrement mal pensé ici.

Le gros manque de Gimp en ce qui me concerne est l'impossibilité de traiter des images avec 16 bits par canal & j'aurai tendance à penser que c'est une limitation dûe à l'implementation initiale. Malgré tout je sais que beaucoup de boulot a été fait entre la v1 & la v2 pour nettoyer le code & le design du programme malheureusement, le passage à 16 bits par canal a l'air d'être carrément dur à faire puisque c'est repoussé à la prochaine release depuis plusieurs années.