GPL a écrit 155 commentaires

  • [^] # Re: Non

    Posté par  . En réponse au journal WebKit - Gecko : 2 - 0. Évalué à 1.

    Merci! (perso j'avais laissé tomber car argumenter avec des gens qui confondent le paradigme objet avec le langage... fatigué moi)
  • # Nooooooooooooon?????

    Posté par  . En réponse au journal cela ne vous rappelle pas quelqu'un?. Évalué à 3.

    Tu veux dire qu'ils pourrissent les forums de linuxfr??? Mais qui aurait cru??? Avec une normalisation de ohohxmleuh d'une transparence et régularitée exemplaire, ce sont des personnes dont la moralité est irr-é-pro-chable! Je ne parle pas de la rigueur et de la simplicité de leur norme qui est ex-tra-or-di-naire!
  • [^] # Re: Non

    Posté par  . En réponse au journal WebKit - Gecko : 2 - 0. Évalué à 1.

    Belle analogie!

    Je vais faire sur le même niveau mais avec l'excès dans l'autre sens:

    "Je ne supporte pas de manger mon haricot vert si celui-ci n'est pas déposé dans ma bouche par la fourchette Two thousand and eight!
    La fourchette Two Thousand and Eight vient livrée avec sa centrale nucléaire et son datacenter. Bien entendu au cas où la centrale nucléaire tchernobylerait, la fouchette Two Thousant and Eight est livrée en standard avec un backup à l'énergie solaire avec son rayon solaire viendant de l'espace avec son satellite géostationnaire intégré!
    La fouchette Two Thousant and Eight, simplifie ton quotidien pour manger ton haricot vert!"
  • [^] # Re: Non

    Posté par  . En réponse au journal WebKit - Gecko : 2 - 0. Évalué à 1.

    Tu as tout à fait le droit de ne pas être d'accord sur ce genre de limites merci de le faire savoir.

    Comme j'ai le droit de ne pas être d'accord avec les tiennes et de le faire savoir.
  • [^] # Re: Non

    Posté par  . En réponse au journal WebKit - Gecko : 2 - 0. Évalué à -1.

    Qu'un langage compliqué à compiler est forcément moins bon qu'un autre plus simple à compiler ?

    Si tu te places dans le contexte qui consiste à considérer la complexité de l'ensemble de la pile logicielle dont dépend le programme en question, un langage délirant à mettre au point est évidement moins bon. Ça ne va pas chercher plus loin. C'est une priorité/une limite comme une autre.

    Je suis un développeur soucieux de la simplicité de la totalité de la pile logicielle. Dans cette optique, il n'est pas possible de considérer le C++ et similaires car la complexité d'un compilateur C++ lambda est délirante donc explose les limites que je me suis imposées.
  • [^] # Re: Bravo!

    Posté par  . En réponse au journal WebKit - Gecko : 2 - 0. Évalué à 0.

    La VM dans Gecko2 (Tamarin), est déstinée à exécuter le javascript des pages web. Faudra donc que tu expliques en quoi ça va apporter "son lot d'appli web riches proprio". Du javascript reste du javascript. Ça va pas se transformer en flash ou je ne sais quoi hein. Surtout que bon, pour que la VM puisse executer du flash, il faudrait l'API flash et sa lib derrière, hein, et ça c'est pas du tout au programme.

    On verra quand le W3C normalisera une VM...

    Et puis si ils ont choisi d'utiliser une VM, c'est bien parce que ça va apporter un plus par rapport à spidermonkey, en terme de perf &cie. Ils ont pas fait ces choix à l'aveuglette pour le bon plaisir d'adobe. D'autant plus que Tamarin a une certaine avancée dans l'implémentation de Javascript 2...

    L'interpreteur (sans VM) est largement suffisant pour des interfaces graphiques. Et cela nous protège des applications riches web propriétaires bien mieux.


    Bon et puis je vois pas ce que viens faire le troll C++ vs C la dedans... Webkit est fait en C++, idem pour Kjs (moteur JS de webkit), et pourtant tu n'en dis rien.

    Relis moi: je préfère le spidermonkey de maintenant, pas celui qu'adobe nous prépare.
  • [^] # Re: Bravo!

    Posté par  . En réponse au journal WebKit - Gecko : 2 - 0. Évalué à -2.

    Qui vivra verra...

    J'attend le moment où le W3C va normaliser une VM à byte code...
  • [^] # Non

    Posté par  . En réponse au journal WebKit - Gecko : 2 - 0. Évalué à -1.

    Écrit un compilateur C++ (pas d'optimisation). Juste le respect des spécifications du language (Faut qu'il encaisse Boost et la STL quand même).

    Écrit un compilateur C (pas d'optimisation non plus).

    Et là... miracle! Tu réalises pourquoi!
  • [^] # Bravo!

    Posté par  . En réponse au journal WebKit - Gecko : 2 - 0. Évalué à 0.

    Exactement ce qu'il ne fallait pas faire! Une VM pour le web! Cela va apporter son lot d'applications web riches proprios.

    Hum la belle m... qu'ils nous préparent pour le web!

    Un des seuls trucs sur la bonne voie comme spidermonkey et bien paff! Ils dropent ce qui était bien dedans pour recoder en C++.

    Quand on voit les participants, et bien je ne remercis pas adobe car manifestement ce sont eux qui ont réussis à faire un coup d'état sur la communauté de mozilla.
    Il semblerait que toutes ces mauvaises idées soient essentiellement les leurs. Faut dire je n'attendais pas plus de la part des personnes qui ont fait flash.

    Je comprend *beaucoup* mieux pourquoi epiphany fuit gecko maintenant, puisqu'il semble très très mal tourner... remarque tu vas me dire qu'avec mono, gnome ça ne sent pas plus la rose non plus.
  • [^] # Re: erreur

    Posté par  . En réponse au journal WebKit - Gecko : 2 - 0. Évalué à 1.

    Si tu as le temps, est-ce qu'il te serait possible de nous founir les liens sur la Mozilla 2 road map?
    C'est juste histoire de nous mâcher le travail...
  • # mouaif

    Posté par  . En réponse au journal WebKit - Gecko : 2 - 0. Évalué à 0.

    On a déjà Gecko en C++ mais eux au moins ils ont spidermonkey qui est en C. Donc sur ce point c'est moins pire que WebKit.

    gobject ne semble être là que pour jouer d'interface sur certains modules. Si j'en crois les rumeurs, gobject semble plus propre que le XPCOM de Mozilla. Donc sur ce point ça serait moins pire que Gecko.

    Gecko semble (j'ai pas essayé) très difficile à extraire de l'usine à gaz de mozilla. Webkit est un module bien indépendant. Ça c'est moins pire que Gecko.

    Bref... ce qu'il faut c'est un renderer web en C optimisé pour les achitectures modernes: optimisation sur les caches de nos machines multicœurs sans ignorer les capacité de nos GPUs modernes. Bon quand on doit mixer un rendu CSS avec du SVG... j'imagine ça ne doit pas être fun car sacrément barré.

    YaKa? Dsl mais la première étape c'est le GPU... ensuite on verra pour le renderer web.
  • [^] # Re: Bon ...

    Posté par  . En réponse au journal Résultat définitif ratification MS-OOXML. Évalué à 3.

    MS n'a jamais rien repompe de ce cote la, ils ont achete leur pile IP initiale a une societe, qui elle l'avait repompe. MS se foutait pas mal que le code vienne de BSD ou d'ailleurs, ils voulaient une pile IP.

    Tiens... je sais maintenant pourquoi je ne fais pas de code BSD...
  • [^] # Re: La liste des votants...

    Posté par  . En réponse au journal Résultat définitif ratification MS-OOXML. Évalué à 3.

    Très bien... et cette liste de participants? Où est-ce qu'on peut la récupérer? Est-ce qu'on sait qui a pris la décision finale?
  • # La liste des votants...

    Posté par  . En réponse au journal Résultat définitif ratification MS-OOXML. Évalué à 4.

    En effet, il serait intéressant de mettre des visages sur toute cette affaire.

    Pour chaque pays, on doit pouvoir obtenir la liste des personnes qui ont commises ce... cette.... qui ont discréditées l'ISO pour beaucoup d'entre nous.

    En effet, ce sont soient des ignorants qui se sont faits berner, soient des êtres... bref...
    Je sais que les gens changent mais je préfère savoir quand je me frotte à une personne qui a été à la source d'un évênement comme celui-là...

    Il faudrait s'en souvernir.
  • [^] # Re: Il y aura des pressions...

    Posté par  . En réponse à la dépêche Suites de l'aventure de la normalisation du format OOXML. Évalué à 2.

    Est-ce que pour être accepté à l'ISO, une sorte d'implémentation de référence libre de qualité respectable doit être présentée avant le processus de standardisation? Genre pour ODF, il y a openoffice et surement bientôt abiword et kword (si ce n'est pas déjà fait). Si c'est effectivement le cas, aucune chance qu'il soit adopté car il n'en existe pas et la réalisation d'une telle implémentation est pure fantaisie selon ce que j'ai entendu sur sa complexité, taille et pseudo-rigueur minable.
  • [^] # Re: Casser en plusieurs moceaux evolution et EDS.

    Posté par  . En réponse au journal Encore merci evolution..... Évalué à 2.

    Outre le r de morceaux qui s'est volatilisé... ce que je voulais dire, c'est casser evolution en plusieurs morceaux ET casser EDS en plusieurs morceaux... divide and conquiere. Par exemple tu sépares le système d'agenda du système de message, et tu les fais communiquer entre eux. J'avais proposer une interface dbus simple pour la communication, c'est à dire pas brain damaged (cf. le bidule immonde qu'est ohohxmleuh).
  • # Casser en plusieurs moceaux evolution et EDS.

    Posté par  . En réponse au journal Encore merci evolution..... Évalué à 2.

    Evolution/EDS essaye de faire pleins de choses en même temps. Déjà c'est pas très unixien (1 et 1 seule chose bien qui communique avec les autres).
    Il faut fractionner ses fonctionnalités en programmes/modules (déjà calendar et messaging), ces derniers pouvant s'échanger des infos via dbus. Par contre c'est pas une raison pour faire des spécifications dbus dignent d'OOXML...
  • [^] # Re: Il y aura des pressions...

    Posté par  . En réponse à la dépêche Suites de l'aventure de la normalisation du format OOXML. Évalué à 8.

    Hum... je pense plutôt à une carte de crédit d'un compte anonyme aux Îles Caïmans. Autre solution: tu fais le mal, ensuite tu te casses du pays avec un compte étrangé rempli pour le reste de tes jours dans un paradis (et voui, certaines boîtes ont largement les moyens d'employer de tels procédés).
    On peut prendre l'example des ripoux de l'industrie pharmaceutique américaine: ils se font élire, passent des lois qui favorisent vachement leurs copains, plombent les autres... ensuite ils quittent la politique quelques années plus tard et on les retrouve au conseil d'administration des boîtes de leur copains avec des salaires de millions de $ par an.
    C'est bô quand le capitalisme sauvage dance avec la politique...
    beurk!
  • [^] # brainstorming

    Posté par  . En réponse au journal Accélération 3D ATI : Ça débute !. Évalué à 4.

    La cible est le modesetting/TTM dans Linux.
    Le reste en user space avec Gallium3D.

    Les interfaces pour le modesetting dans le kernel sont toujours en brainstorming intense (c'est pour ça que marcheu sur nouveau pousse sur randr1.2 en user space). Le TTM semble assez stable mais je n'y mettrais pas ma main à couper. Pour ce qui est de Gallium3D, on en est vraiment au début, il va certainement y avoir pas mal de modifications.

    Pour OpenGL3, rien en vue. Carmak a fait une conférence comme quoi un des moyens les plus sûrs dans le design d'APIs est de faire du code avec mise en condition réèlle... c'est ce qui se passe actuellement autour de la nouvelle pile graphique pour Linux. Je ne serais pas étonné si les designers d'opengl3 suivent de près la conception de cette pile.
    Le pb principal est qu'opengl2 n'est plus du tout adapté aux GPUs modernes ce qui rend la conception d'un driver un vrai cauchemard. La nouvelle pile graphique pour Linux veut des interfaces modernes et donc fait un break avec l'esprit d'opengl2 (il y aura la compatibilité avec opengl2 via mesa).

    Une chose, les GPUs deviennent épouvantablement complexes, ce qui va rendre leur reverse engineering presque déraisonnable. En gros, c'est maintenant qu'il faut agir.
  • [^] # Re: Vidéo

    Posté par  . En réponse au journal Pourquoi Git m'importe ?. Évalué à 3.

    La vidéo est vraiment sympa et la référence à House est bien vue.
    Je me suis mis à GIT depuis que je me suis mis dans la tête de bosser sur la nouvelle pile graphique pour linux.
    J'avoue que je retouve fidèlement tous les avantages dont il parle. D'ailleurs maintenant, j'ai du mal à supporter les contraintes d'un système centralisé (CVS/SVN me donnent des boutons).
    Bref... j'invité vraiment les projets open source à passer sous GIT. En plus c'est du C sous GPL donc du vraiment bon.
  • [^] # Re: DRM inside

    Posté par  . En réponse au journal M6 replay : le site qui n'aime pas linux.. Évalué à 5.

    Ils savent que firefox n'est plus négligeable en France. Je ne crois pas qu'ils ignorent ce fait, surtout quand on conçoit un site destiné au grand public: ils l'ont donc fait en toute connaissance de cause.
    Je me demande bien quel collectif d'entreprises à bien pu les pousser à faire cette boulette et cela avec quels "arguments"?
    Je me le demande, vraiment, hein. Peut-être que ct les mêmes "arguments" qu'un certain collectif à utiliser sur la mairie de Paris récement? Qui sait?
  • [^] # Re: Vidéo

    Posté par  . En réponse au journal Pourquoi Git m'importe ?. Évalué à 1.

    Puta** de flash de mer**!

    Est-ce qu'une bonne âme peut récupérer le .flv et le mettre sur un service comme dl.free.fr

    merciiiiiiiiiiiiiiiiiii!
  • [^] # Re: Le Web vidéo...

    Posté par  . En réponse à la dépêche Schrödinger 1.0 : le codec Dirac est prêt. Évalué à 0.

    TRÈS TRÈS mauvaise nouvelle: il n'y aura pas de support de l'élément <vidéo> ainsi que de lecteur vidéo DOM dans firefox 3.
  • [^] # Re: CPU/GPU nécessaire?

    Posté par  . En réponse à la dépêche Schrödinger 1.0 : le codec Dirac est prêt. Évalué à 4.

    Vu et la nouvelle pile graphique pour Linux se penche sur le sujet:
    http://www.freedesktop.org/wiki/Software/vaapi
  • [^] # Re: Qualité ?

    Posté par  . En réponse à la dépêche Schrödinger 1.0 : le codec Dirac est prêt. Évalué à 2.

    D'ailleurs pour avoir une source vidéo la plus "dirac" possible, je crois qu'il y a des plans de design libre d'une électronique spécialisée dans la compression en "dirac pro" afin que des caméras puissent directement compresser en "dirac pro" le flux non compressé.

    En attendant... :) est-ce qu'il existe des torrents de vidéos HD non compressées? J'imagine qu'ils ne doivent pas être tous petits petits. Avoir différents type de séquences (beaucoup de details avec mouvement rapide/lent, sombre, éclairé, gros objects etc... etc...) on pourrait voir ce que donne, un plus pertinement (je sais que c'est très subjectif), les codecs en rapport compression/qualité (cas d'un flux HD).