Cook Captain a écrit 216 commentaires

  • [^] # Re: Pourquoi six mois ?

    Posté par  . En réponse au journal Changement des conditions générales de vente de France Telecom. Évalué à 2.

    M'est avis que ces bouts de cuivre devrait être une propriété privée : celle du client !

    De toute manière, la situation actuelle est de loin plus favorable qu'à l'époque du monopole. La concurrence a sérieusement fait baisser les prix. Par ex. ma facture a diminué de plus de moitié en 2 ans (pour un service accru).
  • [^] # Re: Superbe initiative

    Posté par  . En réponse à la dépêche Enfin un FAI ADSL associatif !. Évalué à 0.

    parce que dans la réalité, je préfèrerais sans doute free à fdn qui fournit un service plus important pour globalement moins cher,

    En gros, t'es pour le commerce équitable, mais pas si c'est pour partager tes sous.

    et FT peut faire plus ou moins ce qu'il veut avec l'argent qu'il a gagné

    Quel scandale! On devrait en parler à l'ART. Au passage, si t'as peu d'argent, j'ai quelques bonnes idées de ce que tu pourrais en faire:-)


    -----------------------------------------------------------------------------------
    Les Sans Radio : http://www.ville-bagnolet.fr/index.php?pge=416(...)
  • [^] # Re: Oui, mais.....

    Posté par  . En réponse au journal Mac OS X sur x86. Évalué à 3.

    .. tellement que Windows XP me fait penser à ce bon vieux Système 7.5 Bugé jusqu’à la moelle, vieillissant...
    Je suis un AppleManiac depuis mes 12 ans

    Venant d'un "applemaniac" C'est bizarre comme réaction.
    A l'époque (en 96), quand je disais aux Applemaniac que macOS 7 était aussi pourri (peu stable en tout cas ) que Windows 95, ils me prenaient pour un débile...

    les ingènieurs d’Apple ont suent (sic) tirer partie d’UNIX en poussant a son paroxisme la stabilité de ce système. N’oublions pas non plus que MacOSX n’est ni plus ni moins que OPENSTEP pour Mac, un OS révolutionnaire...

    N'exagérons rien quand même.

    Moi j'aime bien aussi mac os X, et j'ai même acheté un mac mini pour développer sous cet environnement. Quelques déconvenues malgré tout.

    Je veux le passer à un giga de Ram, on peut pas ouvrir la bête (clipsé à force) et en plus on perd la garantie si on le fait. (j'avais pas penser à le demander au vendeur, j'suis plus vraiment habitué aux architectures fermées)

    2 mois aprés cet achat, 'Tiger' sort. Faut que je paie à nouveau 120 ¤uros pour avoir la dernière version de l'os. (et sans doute autant l'année prochaine pour le prochain félin). A noter, l'upgrade pour ceux qui ont acheté une machine dans le mois précédent la sortie de Tiger était de 25¤ en France à comparer au 9$ aux US.

    Ils abuseraient pas un peu chez Apple :-(
  • [^] # Re: Terroriste!?

    Posté par  . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 6.

    C'est un article sérieux et bien argumenté. En conclusion, il propose une sentence bien pire que la mort :
    "...Most painful of all for any geek, make him use Windows 95 for the rest of his life."
  • [^] # Re: Si on commencait par la GPL2

    Posté par  . En réponse à la dépêche Version 3 de la GPL : les coulisses de l'adoption. Évalué à 3.

    Certes la licence (GPL ou non) fixe des droits . Ensuite, c'est aux ayant-droits de les faire respecter. Généralement via des actions en justice.
  • [^] # Re: constance des résultats, qualité du benchmark

    Posté par  . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 1.

    Bof ! Il pourrait y avoir des erreurs systématiques.
    1+1=3, 1+2=4, 1+3=5. Conclusion: comme à chaque fois que je rajoute 1, je trouve 1 de plus, c'est que l'addition doit être bonne.

    En physique, c'est le genre d'erreurs qui peuvent être trés difficiles à déceler.
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 0.

    Les .class ne sont pas généralement pas gardés en mémoire, seules les métadonnées et le code de l'application plus le code de la JVM, ce qui est déja pas mal.

    Le couple VM/appli nécessite donc plus de mémoire qu'une appli classique et les temps de lancement ne sont pas négligeable. En revanche les temps d'éxécution sont plus comprable à ceux d'u langage classique.
  • [^] # Re: du déjà vu

    Posté par  . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 3.

    http://www.shudo.net/jit/perf/(...)

    Voici un bench un peu plus sérieux que le shootup...
  • [^] # Re: Un peu fumeux...

    Posté par  . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 5.

    Euh... j'ai vu des programmes en Perl d'une seule ligne dont le développeur avait du passer un certain temps à l'écrire.
  • [^] # Re: interesting alternative programs

    Posté par  . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.

    Comme tout ce bench est inepte, c'est également stupide de ne pas utiliser les fonctions intégrées des langages: quand qq va utiliser Python, à moins d'être taré, il va pas s'amuser à réécrire un tri par tas (sinon on pourrait également interdire les pointeurs en C, les listes en OCAML, etc...).
  • [^] # Re: C comme les sondages ce truc :)

    Posté par  . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 2.

    Imagine des sondages dont les questions et le nombre de questions ne sont pas les mêmes en fonction des sondés, j'ai du mal à croire que statistiquement, on puisse en tirer grand chose...
  • [^] # Re: interesting alternative programs

    Posté par  . En réponse à la dépêche Langages et performances : les Français à l'honneur !. Évalué à 4.

    Au moins une des raisons : ces micro-benchmarks sont trés courts et prennent en compte le temps de lancement des interpréteurs qui sont alors fortement défavorisés.

    Comme d'habitude, ces benchs ne valent que par ce qu'ils testent et ne sont intéressants que si tu comptes développer le même genre de programme.

    Je ne parierai pas un seul kopek sur une formule 1 pour gagner le Paris-Dakar.
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.

    Je vois pas le rapport. entre les patchs, les maj et les exceptions conditionnelles.
    Je réexplique une dernière fois :


    Faut être trés con pour redistribuer une appli avec une nouvelle lib sans la recompiler ne serait-ce qu'une fois.

    En C# tu n'aurais jamais eu le même problème, le runtime aurait vu la différence et aurait tout simplement switcher l'appli pour la faire utiliser la vieille version 1.0
    Ce qui n'aurait de toute manière rien amélioré, étant donné qu'il y a un bug dans la librairie 1.0. (de ton exemple). Donc, dans ce cas c'est blanc bonnet et bonnet blanc. Soit tu as un pb dans le code de la librairie, soit dans le code de ton appli.
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.

    J'essai justement de montrer que Java fait l'erreur de boxer les types primitifs dans leurs équivalent objet (et donc non géré par le processeur) pénalisant fortement la gestion des listes de ces types ! Je vois clairement la différence puisque je la mets largement en évidence
    Evidemment si tu est droitier et que tu joues au ping pong de la main gauche tu seras moins performant. Si tu lis mes posts tu t'apercois que le problème que tu cites est sans incidence réelle. Cela ne remet pas ni en cause Java ni les langages à base de VM. Comme dans tous les langages des choix sont faits, il s'agit souvent de compromis. Prendre un exemple bien précis (exemple bidon et facilement contournable) pour dénigrer un langage comme tu le fais est malhonnête. De la même manière je pourrais prendre un code le 3 lignes en assembleur et écrire, ou la! le C#, c'est complèment pourri, regardez comme c'est lent par rapport à mon code assembleur. Libre à toi de penser le contraire.
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.

    Tu m'expliqueras alors pourquoi les plus gros sites WEB sont aujourd'hui développé en Java. Vu comme tu parles, je suis sur que tu n'as jamais codé plus de 3 lignes en Java. Faire un gros projet en C/C++ ça devient vite l'enfer, gestion des threads misérable, gestion de mémoire inexistante, librairies standard indigente, etc. au final l'appli est toujours moins fiable et parfois moins performante.

    Ce débat me fait penser à celui de C vs assembleur qu'il y avait quand j'ai commencé à développer vers 1985. Aujourd'hui plus personne n'utilise l'assembleur (à part qq cas trés particuliers), et pour les mêmes raisons, demain peu de programmeurs utiliseront le C/C++. C'est l'évolution naturelle de l'informatique - que tu le veuilles ou non. Maintenant rien ne t'empêche de rater le train et de continuer à programmer 2X moins vite avec 2X plus de bugs en C.
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 0.

    Quand tu attaques libgtk en C# tu as exactement les mêmes contraintes qu'en java. A savoir que tu es dans un environnement unsafe. Point.

    mais comme je te l'ai montré c'ests bancale, notamment en cas de patch ou maj, donc c'est pas robuste pour 2 sous.
    Je vois pas le rapport. entre les patchs, les maj et les exceptions conditionnelles.

    mieux vaut tout "bloquer" par défaut que de laisser toutes les portes ouvertes en espérant que le programmeur cherchera à les fermer.
    Je n'en suis pas sur. En tou état de cause, une bonne IDE de te permettra de mettre le mot clef final automatiquement. En l'occurence j'apprécie la sollicitude de Microsoft envers nous pauvres développeurs, il n'en a pas toujours été le cas pour les services et les ports de Windows.
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.

    Je vois pas en quoi je ne maîtrise pas le sujet.
    Parce que tu n'as pas l'air de savoir ce que l'on appelle un type primitif. Un type primitif est un type géré directement par le processeur. (int; float, long, double généralement - short, char, uint, etc. étant généralement un sous ensemble des précédents).

    A partir du moment ou tu utilises des types évolués (ie. non primitfs) tu as forcément besoin d'un pointeur et la les perfs en Java et en C# seront exactement les mêmes, généricité ou pas (modulo la qualité de la VM). Et c'est 99,99% des cas.

    Arréte donc de faire une obsession sur la généricité des types primitifs en Java. En réalité c'est extrêmement peu utilisé dans une liste et si tu as des besoins trés spécifiques tu peux tjs utiliser une blibliothèque adéquate trés simplement (il en existe des dizaines).
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.

    Sauf que le libs en question font la plupart du temps appel à du code natif

    N'importe quoi, toutes les libs que je connais, pour gérer des collections de types primitifs en Java sont toutes implémentées en Java. Arrête de propager du FUD. SVP.

    Il existe des types primitifs en Java (comme en C#), car c'est plus performant qu'un pointeur sur un objet (même s'il s'agit d'un struct). T'as déja vu les perfs d'un programme smalltalk ou tous les types primitifs sont des objets. Excuse moi, mais tu n'as pas l'air vraiment de maîtriser le sujet.
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.

    Au sujet de JNI, à partir du moment ou tu attaques une librairie C à partir de code C# tu retrouves exactement les mêmes pb qu'en Java(et heureusement!).

    Pour les exceptions conditionnelles en Java, c'est une question de feeling certains sont pour, d'autres contre. Personnellement, je trouve que c'est plutot une bonne chose, cela avertit le programmeur d'une erreur potentielle (à lui de faire ce qu'il veut ensuite).

    En terme de performance, la clause "final" ne sert à rien pour un bon compilateur, il détectera automatiquement que la classe est finale et pourra ainsi la dévirtualiser. Pour ce qui est de la dérivation.On peut aussi argumenter le contraire, combien d'entre nous n'ont pas pester parce que justement le développeur d'une librairie n'avait pas autorisé la dérivation d'une fonction. Bref les gouts et les couleurs.

    Quant aux références, on peut difficilement faire moins partial, car il s'agit d'une interview d'Anders Hejlsberg, le créateur de C#, il serait étonnant qu'il dise autre chose.
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.

    Comme tout problème, il est relatif. Si tu rencontres ce problème 2 fois sur un millions de ligne de code, je pense qu'il est facile d'y remédier. Encore faut faut-t-il que le code produit soit réellement un facteur de ralentissement. Selon mon expérience, c'est (trés) rarement le cas. Bref on est plus dans le domaine du micro-benchmark sans intéret que dans la réalité.

    "tiens un mot clé que je ne connais pas utilisons le !"
    Eh bien, je crois que justement il l'utisera...

    Dans tous les cas C# ne t'oblige pas à utiliser les structs ou les pointeurs
    Qu'il y t il de mal à utiliser une librairie plus performante. De toute pour éviter l'auto boxing et avoir des perfs max en c# tu seras obligé de faire pareil.
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.

    Ton exemple n'est d'aucune utilité en pratique. J'ai sous les yeux un programme de 67000 lignes en Java et aucune des listes ne contient de types primitfs mais seulement des objets évolués. Si tel était le cas, et si j'avais un problème de perf, j'utiliserai une bibliothèque gérant les types primitifs. Il en existe des dizaines.

    En revanvhe, le "struct"du c# comporte, AMHA, de nombreux problèmes: combien de développeurs ne vont pas comprendre son fonctionnement exacte et faire ainsi des recopies complète de structure plutot qu'une affection de pointeurs. (avec à la clef des consommation mémoire délirante et des problèmes de perf).

    Bref je suis persuadé que l'on verra bcp plus de problèmes de ce type dans un programme en c# que de listes de type primitifs.
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 4.

    Le C++ est compilé pour produire un code machine de la même nature et au même titre que la compilation assembleur. Certaines petites portions de programme peuvent être développées en ASM en ligne dans le code C++ ce qui permet de profiter à la fois du confort de codage du C++ et des performances de l'assembleur sur les points cruciaux.

    En java, C#, en Python aussi, etc.

    En revanche la production de code en pur C++ avec les STL est aussi rapide et, aux désallocation "delete" près, presqu'aussi sûr que la production de code Java.
    Pas du tout d'accord. La STL reste compliquée à utiliser particulièrement avec les templates. Et il faut toujours allouer et désallouer la mêmoire manuellement.

    L'utilisation (à mon avis très naze mais je peux me tromper) de la bibliothèque gc permet en plus de ne pas avoir à libérer les ressources manuellement.
    C'est le moins que l'on puisse dire. C'est extrêment foireux et pour le cas bcp moins rapide du'un bon GC en java.

    Java impose une couche supplémentaire merdique ; la JVM qui interprète le byte code et dont la justification est super discutable.
    La JVM ne fait pas qu'interpréter le code, elle le compile et le transforme en langage machine. C'est particulèrement intéressant pour les langages objets car elle connait la structure exacte du programme et peut ainsi dévirtualiser des appels de fonctions et produire dans certains cas des programmes plus rapide qu'en C++. (je sais que les adeptes du C++ ont du mal à le croire mais c'est la réalité).
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.

    Et cela n'a rien avoir avec Java car 99% du code de OOo et en C/C++. Comme quoi il est parfaitement possible de faire des programmes trés lent avec des langages conventionnels. Pour l'histoire, il faut savoir que StarOffice 5.2 était encore plus lent.
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 3.

    J'ai essayé avec la librarie suivante et je n'ai eu aucun problème de perf :
    http://www.sosnoski.com/opensrc/tclib/(...)

    En fait,Timaniac fait référence à la manière dont sont traités les objets légers (struct) et l'auto-boxing (par ex. les types primitfs encapsulés dans des objets Integer/Float,etc.) en java par rapport à C#. Les implémentations sont différentes, chacune à ses avantages et ses inconvénients, mais cela n'empêche en aucun cas d'avoir de bonnes perfs en Java (comme en C#). De toute manière 99% des problèmes de perfs des applis réelles se retrouvent dans les algos et les libraries. Cf. un cas intéressant : http://www.spindazzle.org/green/wp-trackback.php/49(...) et http://www.spindazzle.org/green/wp-trackback.php/48(...) comme quoi !
  • [^] # Re: Nécessité de Java?

    Posté par  . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.

    > beaucoup de cas d'utilisation c'est lent

    Lequels ? Et si ce n'est pas le cas pour OOo, alors ou est le problème ?

    Quant à moi, je pense que la gestion de mémoire à travers une GC est plutot une bonne chose (java ou autre). Moins de bugs, moins de fuites mémoires, dévéloppement plus rapide, etc. Bref plus d'avantages que d'inconvénients tant que ne développes pas des applications temps réel ou des drivers.