Nicolas Boulay a écrit 16042 commentaires

  • [^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)

    Posté par  (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 2.

    J'ai aussi un EEEPC, j'ai mis un ssd dedans cela change tout :)

    Et puis, je suis passé à 2 Go, il y a quelques mois (30€?), cela aide un petit peu, mais beaucoup moins que le SSD.

    "La première sécurité est la liberté"

  • [^] # Re: Tellement répété…

    Posté par  (site web personnel) . En réponse au journal Privateur.... Évalué à 5.

    "La version "par défaut" autorise la FSF à faire ce qu'elle veut "or later". "

    Oui, c'est juste un moyen pour updater la GPL en cas de soucis, comme la tivoisation ou les brevets qui contournent les droits d'auteurs.

    "Le seul endroit ou la GPL est importante c'est le Desktop. L'écrasante majorité du reste c'est de l'ASF ou assimilé."

    ASF ?
    Linux sur la moitier des serveur web du monde au moins, c'est du desktop ?
    Linux sous android, c'est du desktop ?
    Les télé/camescopes/set top box, sous Linux, c'est quoi ?
    Les DNS, le mail, c'est pour le desktop ?

    "La première sécurité est la liberté"

  • [^] # Re: Où ?

    Posté par  (site web personnel) . En réponse au journal Privateur.... Évalué à 2.

    Non, pas au sens FSF/RMS.

    Le code libre n'est qu'un moyen pour l'utilisateur de réellement contrôlé ses machines et ses données. Le centre est l'utilisateur, pas le codeur.

    C'est le seul moyen de ne pas avoir "d'informatique déloyal" ((TM) RMS), selon la FSF.

    "La première sécurité est la liberté"

  • [^] # Re: Où ?

    Posté par  (site web personnel) . En réponse au journal Privateur.... Évalué à 1.

    Non, justement, ce n'est pas ça derrière la GPL.

    Le but de la FSF était de créé un écosystème, en prenant pour hypothèse que toute le monde n'est pas beau, tout le monde n'est pas gentil. Il parte du principe que quelques soit la quantité de code libre que tu produits, tu en utilisera toujours bien plus. C'est une sorte de paiement à la communauté. Et celle-ci ne peut vivre sans retour des réutilisateurs de code. La plus part des forks de projet libre vers du fermé finissent par mourir.

    Un code libre n'est gratuit quand il a été payé :)

    "La première sécurité est la liberté"

  • [^] # Re: Trollons

    Posté par  (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 9.

    si on peut.

    "La première sécurité est la liberté"

  • [^] # Re: Tellement répété…

    Posté par  (site web personnel) . En réponse au journal Privateur.... Évalué à 2.

    C'est uniquement car cela te fait un peu chier. /o\

    "La première sécurité est la liberté"

  • [^] # Re: Trollons

    Posté par  (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.

    Juste au dessus, il parle de cluter. Il y a de quoi faire, non ?

    Et sinon niveau doc/IDE, il y a des trucs utilisables par des non-experts pour les EFL ?

    "La première sécurité est la liberté"

  • [^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)

    Posté par  (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 1.

    Tu as comparé avec l'outil de montage de blender ? Il m'a l'air bien complet mais très dure à prendre en main.

    "La première sécurité est la liberté"

  • [^] # Re: Trollons

    Posté par  (site web personnel) . En réponse au journal OpenShot abandonne Gtk+.... Évalué à 3.

    Marrant, tu n'as pas utilisé les 3 lettres qui commencent par E et finit par L (avec un F au milieu).

    "La première sécurité est la liberté"

  • [^] # Re: Où ?

    Posté par  (site web personnel) . En réponse au journal Privateur.... Évalué à 2.

    X11 avait aussi un paquet de fork incompatible chez Sun et HP. Idem pour spice, qui avait un fork dans chaque outil propriétaire du domaine.

    Ces fork profitaient du code libre sans rien payer en retour en contribution.

    "La première sécurité est la liberté"

  • [^] # Re: Où ?

    Posté par  (site web personnel) . En réponse au journal Privateur.... Évalué à 2.

    Aujourd'hui, les boite comme Google, joue le jeu de la BSD.

    Ce n'était pas le cas avant, les exemples autour de X11 montrent que la BSD permet de faire n'importe quoi.

    "La première sécurité est la liberté"

  • [^] # Re: Tellement répété…

    Posté par  (site web personnel) . En réponse au journal Privateur.... Évalué à 1.

    D'où le terme de FOS :)

    "La première sécurité est la liberté"

  • [^] # Re: Tellement répété…

    Posté par  (site web personnel) . En réponse au journal Privateur.... Évalué à 7.

    La GPL protège les auteurs orignaux du code sur le fait de ne pas pouvoir changer l'usage de leur code. Et elle protège les utilisateurs.

    Et en effet, elle empêche les réutilisateurs du code, de se l'approprié sans rien donner en retour.

    La BSD fait confiance au gens, pas la GPL. Inutile de préciser, quel écosystème est le plus gros.

    "La première sécurité est la liberté"

  • [^] # Re: un inconvénient des templates

    Posté par  (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 1.

    Disons que le dev d'ocaml était purement universitaire, ils étaient plus intéressé dans le développement des derniers concepts avancés de typage (le dernier type à l'air super puissant, mais je n'ai toujours pas compris son fonctionnement) que dans le fait d'avoir des messages d'erreurs précis et compréhensible, ou un module Eclipse fonctionnel. Ocaml pro veut changer cela, on dirait.

    "La première sécurité est la liberté"

  • [^] # Re: un inconvénient des templates

    Posté par  (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 3.

    cocomo ne mesure pas la difficulté de changement, mais le temps global pour écrire le code. Le problème est que le nombre exacte de kloc est connu à la fin du projet.

    Et si le cout est 100x, c'est parce qu'au début, cela prend 5min pour changer une spec, alors qu'à la fin, c'est le client qui trouve l'erreur, la remonte au support, qui transmet à la validation pour confirmation, qui remonte ensuite au dev.

    "La première sécurité est la liberté"

  • [^] # Re: un inconvénient des templates

    Posté par  (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 0.

    Le problème est assez complexe, avec Ocaml tu peux facilement prédire les données que tu va créé. Haskell dispose d'optimisation dite de "deforestation" qui supprime les arbres de données intermédiaires, quand il le peut. Ocaml n'étant pas purement fonctionnel, j'imagine que la difficulté vient de là.

    "La première sécurité est la liberté"

  • [^] # Re: un inconvénient des templates

    Posté par  (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 1.

    Je pensais plus au fait qu'il était trés difficile de déterminer la taille des données mémoires. Certain industriel avait laisser tomber Haskell car de petites modifications pouvait faire exploser son usage de la mémoire. C'était un des arguments d'OCaml ou sa gestion des objets mémoire est très prévisible.

    "La première sécurité est la liberté"

  • [^] # Re: un inconvénient des templates

    Posté par  (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 1.

    Disons que faire du pthread propre est une vrai horreur. Le vrai multi-process est revenu à l'honneur avec chrome. Il "suffit" d'ajouter une lib de passage de message propre et rapide.

    Mais c'est vrai aussi que des traitements parallèle de data pourrait être sympa (map fold/reduce en multicpu).

    "En dehors de ça, j'ai l'impression que le langage Ocaml recommence à faire parler de lui, après quelques années en sommeil. Un regain pour le fonctionnel ?"

    Peut être est-ce la création de Ocaml pro ? Ou la pub sur l'usage qu'en font quelques boite comme janes street (vive le HFT en Ocaml).

    "La première sécurité est la liberté"

  • [^] # Re: un inconvénient des templates

    Posté par  (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 3.

    #pragma omp for
     for(int n=0; n<10; ++n)
     {
       printf(" %d", n);
     }
     printf(".\n");
    
    

    Cela va te lancer n thread en découpant la clause for en morceau. Le système se débrouille même si tu peux aussi le guider. Sur du code numérique, c'est assez facile du moment que tu comprends que tu ne peux pas partager d'information entre threads.

    Si tu as des ressources intéressantes à ce sujet je suis preneur, si tu estimes que ça permets vraiment d'estimer les coûts d'un projet en fonction des langages utilisés.

    https://en.wikipedia.org/wiki/COCOMO ?

    Je retient surtout : ab*(KLOC)bb. Cela veut dire que la difficulté n'est pas linéaire au nombre de ligne, mais augmente plus vite.

    "La première sécurité est la liberté"

  • [^] # Re: un inconvénient des templates

    Posté par  (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 3.

    openMP n'est pas une api C. Ce sont des directives de compilation pour générer du code multithread.

    "la taille d'un code comme un indice par rapport au fait qu'il soit lisible"

    Non, mais sur sa concision. Il y a eu des études portant sur la productivité (cocomo) quelque soit le langage, la productivité en ligne de code par unité de temps est la même.

    "De quel domaine parles-tu? Dans la discussion, on parlait de façon assez générale il me semble…"

    Je pensais à l'IHM.

    "Ici, ça semble être le calcul scientifique?"

    Non, il y a aussi manipulation de symbole.

    "La première sécurité est la liberté"

  • [^] # Re: un inconvénient des templates

    Posté par  (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 2.

    Le C génére bien de l'assembleur.

    Ces langages étant turing complet et bas niveau, on peut tous faire avec ou presque. Après, il y a une question de verbosité. Le code généré est plus gros, que ce tu ferais à la main, cela décale ton langage vers la gauche dans le graphe.

    Donc, un langage générant du C peut être plus rapide et concis qu'un code C fait main.

    "La première sécurité est la liberté"

  • [^] # Re: un inconvénient des templates

    Posté par  (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 1.

    "Battait, ça veut dire que C a rattrapé Lisaac ensuite?"

    Oui, car lisaac générant du C, c'est facile de comprendre pourquoi il est plus rapide. Au pire, tu copie/colle sa sortie et tu dis que c'est du C manuel.

    "Et sinon, le C++ n'a pas ces problèmes il me semble, et pourtant les bench disent souvent la même chose: il est souvent plus lent que le C."

    Dans le shootout, il est régulièrement premier grâce à openMP et les templates.

    "La première sécurité est la liberté"

  • [^] # Re: un inconvénient des templates

    Posté par  (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 2. Dernière modification le 25 avril 2013 à 16:11.

    "je suis intrigué qu'il n'ait pas réussi s'il est meilleur"

    Le code du compilo n'était pas simple du tout (détermination du type réel de chaque objet). Et le dev principal a coupé les ponts du jour au lendemain.

    Les codes c++ et C utilisent massivement openMP qui n'existe pas dans le monde ocaml.

    "Ce benchmark est à 2 dimensions: taille du code (et pas expressivité) à l'horizontale et vitesse d'exécution sur la hauteur, si je ne me trompe pas?"

    Non, c'est juste l'affichage de ce graph, il est intéressant car la case la plus intéressante est en bas à droite : compact et rapide.

    "ils mesurent la taille du code en octets, en ayant enlevé commentaires et espaces, et en compressant le texte ainsi obtenu. Franchement… je trouve difficile de trouver une façon moins pertinente de mesurer la taille des codes."

    Au contraire, cela évite de parler de la définition de la "ligne de code". La compression limite l'augmentation de taille des langage verbeux par rapport à ceux abusant des symboles.

    "il n'y a que des algo de calcul, donc pas d'accès aux ressources, de gestion d'IHM, et caetera. Donc, comme d'hab avec les bench, résultats à n'utiliser que pour des optimisations des "zones de calcul"."

    C'est vrai. Mais les problèmes de logiciels dans ce domaine, sont liés aux algos utilisés. Il faut aussi que la taille du benchmark reste accessible aux codeurs. Il y a aussi des benchs manipulant des symboles (de mémoire, le truc qui manipule de l'ADN).

    "La première sécurité est la liberté"

  • [^] # Re: un inconvénient des templates

    Posté par  (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 1.

    J'ai écrit et optimier une IA en java. La vitesse est digne d'un gcc -O0, pas d'inline des getter/setter, etc… Cela ne peut pas être rapide, même les "clause if" n'étaient pas sorti des boucles.

    "La première sécurité est la liberté"

  • [^] # Re: un inconvénient des templates

    Posté par  (site web personnel) . En réponse au journal Visiteurs en C++. Évalué à 2.

    Il n'y a pas un seul benchmark, mais une dizaine. L'algo est fixe.

    Haskell vu sa gestion de la mémoire à forcément des cas pathologiques.

    Pas la peine de vendre du rêve!

    Lisaac battait le code C dans la plus part de tests donc bon. Le problème n'est pas de faire un compilo intelligent. Le problème est de faire un langage avec suffisamment de sémantique pour qu'un compilateur puisse faire un boulot intelligent. Par exemple, le C fixe le layout mémoire de ces structures de données, et 2 pointeurs de même type sont censé pouvoir pointé sur la même zone mémoire. Ces 2 caractéristiques peuvent être des killers de performances. En gros, c'est le boulot du codeur, et le compilo ne peut rien faire.

    "La première sécurité est la liberté"