chaperon a écrit 45 commentaires

  • [^] # Re: Anticrénelage ? Bof !

    Posté par  . En réponse à la dépêche Open Motif 2.3 : Anticrénelage, unicode et plus…. Évalué à 5.

    belle et éthérée ou autrement dit floue

    Les polices vectorielles sont floues, oui. Mais les polices TrueType/OpenType/... ne le sont pas forcément.

    Un exemple d'intelligence pure : ProggyFonts (http://www.proggyfonts.com). En utilisant le hinting et en donnant une forme particulière aux polices, on obtient un effet "bitmap".
    Et en faisant un hinting aux petits oignons, on devrait même pouvoir obtenir le même résultat en scalable.

    Créer une vraie police professionnelle est un art complexe, long, éprouvant et faisant appel à des connaissances très poussées, donc le placement "amoureux" de quelques pixels est devenu dérisoire face à l'impressionnante qualité que l'on peut atteindre avec des polices bien faites.
  • [^] # Re: portaudio

    Posté par  . En réponse à la dépêche Open Sound System de retour vers le libre. Évalué à 5.


    Comme par exemple l'excellentissime portaudio http://www.portaudio.com/ que je recommande chaudement


    Ou, pour un autre usage, JACK (http://jackaudio.org), pour qui tous les programmes devraient supporter la sauvegarde de session et le transport synchronisé (avis aux développeurs contributeurs).

    Maintenant, sans vouloir dénigrer ALSA ni les efforts d'OSS, un système audio centralisé sur un démon me semble plus pratique qu'une couche de pilotes qui sait tout faire. Ils devraient se concentrer sur la stabilité et la latence (qui sont déjà remarquables) plutôt que sur les fonctionnalités.

    Donc OSS de retour, c'est une bonne nouvelle, puisque cela fera un meilleur support pour certaines cartes et de toute façon, on va abstraire tout ça derrière une belle lib bien complexe qui fait le travail !
  • [^] # Re: Pour qui ?

    Posté par  . En réponse à la dépêche AMD/ATI va libérer ses pilotes. Évalué à 1.

    Je ne réponds pas sur la première partie des réponses, vu que SDL n'est qu'un sujet de trolls sans fin et une lib qui rend bien des services. Admettons que j'aie eu tort, même si je ne le pense toujours pas ...

    Par contre, pour le C#, c'est assez inquiétant, vu que beaucoup de jeux XBLA sont en C#. Alors ce ne sont peut-être pas des superproductions, mais attention : Ce type de jeu sera peut-être le jeu vidéo du 21ème siècle.

    Qui n'a pas remarqué le type de jeu que fait actuellement Nintendo. N'allez pas me dire qu'un jeu Wii type Wii sports ne peut pas tourner en C# sur une 360. Et comme le marché est encore en train de changer, avec des horreurs techniques genre Nintendo DS (je parle du rendu des jeux, pas de l'input system génial), le C# va prendre de plus en plus d'importance.

    Et la différence avec Java, c'est qu'il y a Microsoft derrière, et Vista+360 imposent une pression énorme dans les choix des développeurs en ce moment. Bref, rien à voir avec l'insignifiant (et méconnu) marché des plateformes libres.
    Quand je dis insignifiant, tout le monde aura vu la légère exagération, mais le principe est le même.

    <mode meme-que-c'est-pas-forcément-vrai-on-s'en-fout-vu-que-les-dev-pensent-tous-ca>De toute manière, linux n'est pas prêt pour le marché de masse. Alors même si tout le monde possède virtuellement une machine sous linux (y'a qu'à l'installer, voire le fournir sur le DVD du jeu), rien ne sert de faire une version avec des technos libres puisque ça ferme la porte de la xbox.
  • [^] # Re: Pour qui ?

    Posté par  . En réponse à la dépêche AMD/ATI va libérer ses pilotes. Évalué à 4.

    Enterré ? Et alors !
    Un jeu DirectX se porte très facilement sous OpenGL si le code est bien fait. Il ne faut pas voir un jeu comme un gros pâté posé comme ça sur une techno. Tous les jeux récents se basent sur un moteur intermédiaire (type Unreal Engine).

    Alors c'est sûr, la demande du marché fait que les jeux passent en DirectX en ce moment, mais les moteurs peuvent en général être passés en OpenGL facilement. Du coup, le fait de modifier un moteur te fais passer facilement 10 jeux du même coup.

    ... Reste qu'il n'y a encore aucun équivalent libre à DirectX qui soit suffisemment sérieux pour ses fonctionnalités supplémentaires : le support joystick, la gestion directe de la souris (pas en mouse grab, une vraie interface qui prend les souris haute résolution). Le son, OpenAL est définitivement la bonne voie (car supporté par Creative). La création de fenêtre de rendu n'est pas non plus très facile en multiplateforme.
    Et le premier qui me répond SDL, je suis au regret de l'informer que c'est hélas insuffisant et un peu mort comme projet (pas de multihead, pas de souris en prise directe, pas de micro, pas de joysticks-de-la-mort avec 45 boutons et 12 axes, ...).

    La meilleure voie est encore de pousser les technos libres en amont (Ogre par exemple) et c'est précisément mon job en ce moment. Mais l'entrave la plus grande reste Microsoft et sa X-Box 360. Sous prétexte de "portabilité" (un jeu PC/360 est dit "multiplateforme", arrgh) tout le monde tente de rentrer dans le moule Microsoft. Attendez-vous à voir de plus en plus de jeux écrits en C# ces prochaines années.
  • [^] # Re: Et PAM ?

    Posté par  . En réponse à la dépêche Linux Slackware 11.0 est disponible. Évalué à 2.

    Tout à fait d'accord : Slackware m'a appris le mécanisme de boot de linux (init, le rc et les scripts) car c'est la seule qui soit suffisement simple pour que les scripts soient lisibles par une personne normalement constituée !

    Ceci dit, le passage à l'init façon systemV (rc?.d avec des priorites) m'a un peu rebuté.
  • [^] # Re: PostgreSQL en évidence

    Posté par  . En réponse à la dépêche Sortie en version alpha du PGI open source Taika Linux. Évalué à -1.

    Tout cela est effectivement intéressant. Je ne savais pas qu'il était question de standardiser le XUL. Reste que ce ne sera jamais implémenté sur la fameuse plateforme propriétaire (déjà que SVG aura du mal à passer).

    Et évidemment, je parle de fournir des éléments en standard, pas de plug-ins que l'utilisateur moyen n'a pas forcément car il est plus simple d'installer directement l'implémentation XUL de Mozilla ...

    En fait, je suis 100% pour cet type d'applis à partir du moment où ce n'est pas un piège à développeurs (type BASIC ou .NET), et vu ta réponse, c'est loin d'être le cas ici.

    Bravo aux gens qui développent de vrais outils avec de vraies technos libres.
  • # PostgreSQL en évidence

    Posté par  . En réponse à la dépêche Sortie en version alpha du PGI open source Taika Linux. Évalué à 1.

    Ravi de voir PostgreSQL en évidence, cela m'aidera peut-être à en faire la publicité. Très bonne base de données, mais disposant d'une faible image de marque.

    Pour en revenir à la distribution, est-ce que les outils proposés sont vraiment efficaces (genre OpenOffice) ou plutôt des outils encore jeunes (genre GNUCash) ? Peut-on réellement envisager un déploiement en PME ? Les outils sont-ils adaptés au système de comptabilité français ?

    Enfin, un gros troll caché sous une montagne de subjectivité : je n'aime pas XUL et je me demande si une alternative libre et réellement standard existe.
  • [^] # Re: En taille réelle

    Posté par  . En réponse à la dépêche Première publication du projet Magrathea. Évalué à 1.

    Le "système solaire avec toutes ses planètes" est GNU ?


    Il ne peut pas être GNU parce qu'il n'est malheureusement pas livré avec les sources. Ou alors si elles existent, elles ne semblent malheureusement pas modifiables (de l'open source non libre !)

    A moins qu'elles existent, mais on n'a pas le compilateur pour refaire le monde (un ptit make world ne devrait pas suffire).
  • [^] # Re: Police pour écran ou pour imprimante ?

    Posté par  . En réponse à la dépêche Fedora lance une campagne de test de la police DejaVu. Évalué à 4.

    Mon exemple restait un exemple.

    Pour les autres problèmes que tu avance, les formats modernes (OpenType notamment) sont capables de tout gérer ou presque (le presque est infime). Toutes les joyeusetés nécessaires au rendu des polices sont inclues.

    Pour ta question sur les algos spécifiques, cela dépend de l'implémentation. Toutes les informations nécessaires au fonctionnement des algos sont fournies dans la police. En revanche, l'interprétation de ces infos sont gérées par les différentes implémentations. On peut imaginer une implémentation spécifique par modèle d'imprimante, par écran, mais en général, les bibliothèques généralistes font de l'assez bon travail pour un usage courant.

    Je pense que cette campagne de test souligne bien la complexité énorme de ce travail, et ils devraient bien expliquer qu'il faut soumettre les polices à toutes sortes de médias de sortie (imprimantes de tous types, écran, je ne sais quoi encore ...).

    Mais comme apparament leur priorité est le support d'un maximum de langues, aucun cas n'est fait de ce genre de problèmes.
  • [^] # Re: [supputations]

    Posté par  . En réponse à la dépêche Microsoft se met à l'Open Document. Évalué à 0.

    Mais il y a déjà tellement à faire en poste par poste sur une install d'office par défaut. Paramétrer les données personnelles, enlever cette sal... de compagnon office, régler 2/3 barres d'outils, installer un export PDF, vérifier les configs des filtres de macros, installer un antivirus, je ne parle pas du réglage de Outlook (qui, je vous le rappelle, fait partie d'Office), ...

    Bref, les administrations sont rodées à ce genre de manips en install poste par poste. En plus, comme rien n'est automatisable dans office (ou si peu ...), tout cela est fait a la main, avec une procédure généralement sur papier.

    Donc l'installation d'un filtre supplémentaire ne devrait pas trop poser de problèmes, à moins qu'il ne fasse 70 Mo et aie 5 écrans de paramétrage pour fonctionner correctement. Il faut simplement qu'il soit connu des administrateurs qui pondent les procédures d'install et OpenDocument sera au moins lisible directement. Quant-à le paramétrer comme format par défaut, la marche est encore haute.
  • [^] # Re: Police pour écran ou pour imprimante ?

    Posté par  . En réponse à la dépêche Fedora lance une campagne de test de la police DejaVu. Évalué à 10.

    En fait, les formats utilisés actuellement doivent en théorie s'affranchir de ce problème, ainsi que de la faible résolution des écrans.

    Une police vectorielle (composée de lignes et de courbes plutôt que de pixels) est peu lisible si tracée telle quelle sur un écran. Ceci est dû à la résolution très limitée des écrans actuels (120dpi dans le meilleur des cas). Par exemple, un "E" peut avoir ses deux branches horizontales supérieures accolées s'il est tracé trop petit : il devient illisible sur un écran mais reste parfait sur une imprimante.

    Pour corriger ces effets indésirables, on utilise le hinting (S.V.P. trouvez-moi la traduction en français) : cela consiste à décaler d'un pixel ou deux les fameuses branches horizontales du E (toujours dans mon exemple). De cette façon, le E est toujours lisible sur un écran à basse résolution (quoique déformé par l'opération).

    Et le hinting est une opération complexe, mettant en oeuvre une sorte de langage de programmation (dont le bytecode pose des problèmes de license dans TrueType).

    C'est cet aspect universel qui est dur à obtenir dans les polices actuelles, et comme le soulignent les posts plus haut, concevoir une police est un travail de titan ... surtout quand la police est unicode (plusieurs dizaines de milliers de symboles).
  • [^] # Re: La différence fondamentale

    Posté par  . En réponse à la dépêche Test d'Ubuntu 6.06 LTS. Évalué à 2.

    ... Surtout que Gentoo (stage 1 notamment) est à mon avis plus chiante à installer qu'une slack.
  • [^] # Re: Des pb d'installation, il y en a, et personne n'en parle

    Posté par  . En réponse à la dépêche Test d'Ubuntu 6.06 LTS. Évalué à 0.

    Mais qui fait encore des /boot ?

    Sérieusement, le /boot était là au départ pour que l'image noyau soit avant le 1024ème secteur du disque car au delà, lilo ne pouvait pas y accéder.

    Sinon, aucun intérêt particulier, et surtout pas celui de booter quand même malgré une partition / plantée car pour booter, on a besoin de /etc/inittab.

    Et pour ce que sert cette partition, de l'ext3 est amplement suffisant.

    Je tolère à peine les /tmp dans une partition séparée, alors les /boot ...

    P.S. tout ceci n'est valable que pour un desktop.
  • [^] # Re: et du côté de Debian...

    Posté par  . En réponse au journal Sortie de Ubuntu 6.06 Release Candidate. Évalué à 1.

    Destroyed Daffy


    Excellent nom pour une distrib ! Y'a des royalties ?
  • [^] # Re: et du côté de Debian...

    Posté par  . En réponse au journal Sortie de Ubuntu 6.06 Release Candidate. Évalué à 2.

    Ouais, enfin relativisons.
    Je suis passé à Ubuntu (pour le desktop) dans l'unique but d'avoir des softs plus à jour, mais je n'ai pas tenu 5 minutes avant de passer en dapper (alors qu'elle était à peine dispo en instable).
    Quand on en veut toujours plus, on est en instable et on fait des bugreports au lieu de râler.

    Et avec mes problèmes de LVM avec le noyau 2.6.16.18 sous debian sarge (compilé correctement avec kernel-package), je songe à passer à ubuntu aussi pour le serveur (petit serveur mais professionnel quand même).
  • [^] # Re: Pourquoi propriétaire?

    Posté par  . En réponse à la dépêche Virtualisation complète avec kqemu. Évalué à 3.

    Ce buisness-model m'a l'air bien, du moins de la façon dont je le comprends.

    D'après ce que je comprends, il ne vendra le code (ou le droit de l'utiliser) à personne. Il veut récolter une certaine somme, à partir de laquelle il libèrera le code.

    Donc, d'après ce que je comprends (et je peux comprendre de travers), si VMWare sponsorise kqemu, kqemu deviendra libre, et non pas propriété de VMWare.

    Si c'est bien ce que j'ai compris, alors je trouve le modèle très réglo, surtout que le module proprio est gratuit (ce qui n'est pas rien).
  • [^] # Re: DRM, comprend pas comment c'est impiratable.

    Posté par  . En réponse à la dépêche Appel à tous: Jeudi 30 mars, action (silencieuse) contre la loi DADVSI. Évalué à 3.

    4/ les flux DRMisés, serotn à terme lisible que sur une chaine sûre


    Oui, sauf que les haut-parleurs seront toujours fabriqués avec des bobines dans lesquelles passe un courant proportionnel au signal. Il suffit de donner un grand coup de savate dans l'enceinte (une enceinte à 2 balles suffit), de récupérer le fil de la bobine, de le couper en son milieu et de reconnecter tout ça sur une entrée ligne de PC.

    A moins qu'ils fassent des haut-parleurs surblindés, je vois pas !

    Et après, quel sera le rôle de l'ampli ? Si le signal transite en numérique de la source aux enceintes, vu que le convertisseur sera dans l'enceinte, je vois plus l'utilité de l'ampli, qui sera dans l'enceinte.

    Et quelles seront les conséquences sur qualité audio de ce type de chaine ? (je parle en très haut de gamme)
  • [^] # Re: GStreamer et DRM

    Posté par  . En réponse à la dépêche Sortie de GNOME 2.14. Évalué à 4.

    Plutôt intéressant, mais ne résoud pas le problème des moteurs de thèmes, radicalement différents. Dommage que gtk-qt fasse l'inverse de ce que je souhaite (j'utilise GTK majoritairement, et je souhaiterais que les applis QT utilisent le thème GTK).

    En plus, les moteurs ont quand même des capacités similaires, et sont donc unifiables facilement.

    En bref, les problèmes de widgets sont loin d'être résolus. Et je ne parle pas de OpenOffice/Firefox/Motif/Tk/<you name it>
  • [^] # Re: GStreamer et DRM

    Posté par  . En réponse à la dépêche Sortie de GNOME 2.14. Évalué à 2.

    D'ailleurs, je verrais bien une norme pour les thèmes graphiques. Avec tous ces moteurs de thèmes, et l'existance de gtk-qt montre un peu le chemin à quivre.

    D'après ce que j'ai compris, le dessin des boutons dans QT et GTK sont réalisés par des modules enfichables. Pourquoi pas un format commun ?

    Quitte à réaliser un moteur complexe ayant les capacités des deux, mais c'est juste histoire d'en finir une bonne fois pour toute avec les gueguerres de look et histoire de simplifier la vie des créateurs de thèmes.
  • [^] # Re: doublons dans les stats ?

    Posté par  . En réponse à la dépêche DADVSI : suite.... Évalué à 2.

    Remarque : il n'y a pas beaucoup plus de risques de faux que lors d'une pétition manuscrite. Le seul facteur aggravant est la masse énorme du public sollicité (potentiellement tout internet via google).
  • [^] # Re: Retour de FUD... à la mode

    Posté par  . En réponse à la dépêche Le ministère de la justice belge passe à Linux et OpenOffice.org. Évalué à 1.

    Je suis 100% d'accord, mais j'ai eu une mauvaise surprise récemment.

    Un ami a essayé Ubuntu : pas de réseau (3com gigabit) et pas de graphiques (NVidia très récente). Forcément, ça refroidit de se retrouver devant un login texte sans moyen de télécharger les drivers proprio requis pour ces périphériques.

    Donc linux, c'est très bien, mais à condition de faire comme moi : vérifier systématiquement la compatibilité du matériel avant d'acheter.

    Constructeurs, s'il vous plaît, ouvrez vos specs, ou mieux, faites des drivers libres ... [doux rêve]

    Tout ça pour dire que linux, c'est trop facile, mais seulement quand on a le bon matériel et qu'on ne veut pas jouer aux derniers jeux à la mode.
  • # Ils font de bons choix ...

    Posté par  . En réponse à la dépêche Des nouvelles d'Enlightenment DR17. Évalué à 1.

    C'est totalement subjectif, mais je trouve leur choix plutôt bons :

    E17 est prévu pour être léger, rapide et portable

    Très bien, j'en ai marre de voir des GNOME ou des KDE ramer comme pas permis. Plus de 5 secondes pour ouvrir un terminal sur une bonne machine, c'est trop !

    ne veut pas s'attacher à une dépendance aussi forte

    Encore mieux. Vu les commentaires précédents, la porte n'est pas fermée à OpenGL.

    Seul petit problème, Enlightenment utilise son propre toolkit. Et je ne dis pas cela contre E, mais contre les autres : c'est bien dommage que GTK/QT/Motif et les autres soient majoritaires, car j'ai toujours trouvé le toolkit d'Enlightenment un brin plus réactif. Sans parler de l'adaptation aux couleurs personnalisées, où il est souvent impossible de profiter des thèmes en inverse vidéo (fond foncé, texte clair) : E gère cela très bien.

    Dans un monde idéal, une interface commune aux toolkits permettrait d'en changer, tout comme on change de Window Manager ou de serveur X. Vivement des moteurs de thèmes pour GTK et QT qui utilisent le toolkit d'Enlightenment ! On se rapprocherait un peu plus près de l'idéal sans recoder la moitié des toolkits.

    Ce commentaire n'est pas destiné à relancer le troll GTK/QT, mais d'appeler à la comparaison entre les deux "gros" et E.
  • [^] # Re: hum

    Posté par  . En réponse au journal DADVSI: Concrètement, on fait quoi?. Évalué à 4.

    Partout les textes du gouvernement qui défendent cette loi disent que cette loi va garantir l'intéropabilité.


    Je mettrais ma main au feu que les ministres ne comptent pas les ordinateurs comme des moyens de regarder des films ou d'écouter de la musique, mais uniquement comme des outils de piratage.

    Donc quand ils parlent d'interopérabilité, je mettrais mon billet qu'il s'agit d'interopérabilité entre les lecteurs de salon et les téléviseurs, mais certainement pas d'interopérabilité entre programmes informatiques.

    S'ils ne pensent même pas aux ordinateurs, comment se pourrait-il qu'ils songent un seul instant au libre ?
  • # Curiosité ?

    Posté par  . En réponse à la dépêche Les logiciels libres en Algérie. Évalué à 2.

    Juste une curiosité.

    De quelle qualité sont les logiciels libres par rapport aux non-libres en ce qui concerne le support de l'arabe ?
    Ce n'est pas pour moi, mais pour savoir si le libre est prêt à la distribution dans cette langue.
    L'arabe a l'air techniquement très différent de l'anglais, donc je me demandais si l'utilisation par un non-anglophone (ou francophone, car il en reste encore en Algérie) était possible sans trop de prises de tête.
  • # On connait déjà le mécanisme.

    Posté par  . En réponse à la dépêche Les bibliothèques anglaises se préoccupent de la prolifération des DRM. Évalué à 10.

    Juste une remarque : certains connaissent déjà le mécanisme des DRM et leurs dommages potentiels. Ces chanceux sont les passionnés d'émulation !

    Cette comparaison est valable pour les vieux jeux protégés tournant sur de vieux ordinateurs. Je pense aux Amstrad CPC, Atari ST, Commodore Amiga et autres Apple ][. Si des pirates n'avaient pas contourné les protections de la plupart des jeux, nous aurions perdu un patrimoine très riche.

    Exemple : Dungeon Master, dont la communauté de joueurs est toujours active depuis 1987, reste une merveille de programmation en environnements très contraignants (8Mhz, 512k de RAM pour 15 niveaux en temps réel et en pseudo-3D) qui a été récemment retranscrit en C++.

    Autre exemple : Maupiti Island de Lankhor, chef d'oeuvre pour son époque, nous a définitivement quitté dans sa version Atari ST, faute de crack. Les rares copies disponibles à ce jour sont protégées (donc inrecopiables), et toutes ces copies sont défectueuses (les disquettes, c'est peu résistant). Résultat, un jeu en moins.

    Il s'agit donc d'une perte d'un morceau de l'histoire du jeu vidéo ; morceau important qui plus est !

    Tâchons de nous rappeler de cette merveilleuse époque, technologiquement prolifique, mais qui peine à subsister à cause de ses protections.