Même si nous sommes d'accord sur le fond, il faudrait pas sauter tout de suite à une conclusion erronée. Que beaucoup de projets libres naissent et meurent, c'est un fait. Que le choix de la licence GPL en soit une des cause, je reste sceptique.
La menace de non-contribution en retour est brandie en permanence dès qu'on parle de BSD. D'une part, ce risque existe aussi avec les autres licences libres. D'autre part, parce que ce risque existe ne veut pas dire qu'il est réalisé. Il y a des projets BSD qui reçoivent des retours sous forme de patch, de la part d'entreprises qui les utilisent.
Je partage l'avis de l'auteur du fil de discussion. Quand je vois des projets simplistes de bibliothèques, qui choisissent la GPL, je trouve ça plutôt ridicule.
Par exemple readline ( http://tiswww.case.edu/php/chet/readline/rltop.html ). On ne peut pas utiliser la bibliothèque fournissant readline si ne fait pas un programme sous GPL. C'est un choix de l'auteur que je peux comprendre, mais je trouve que c'est plus une perte pour le logiciel libre et les logiciels commerciaux qu'autre chose. Je m'explique :
- readline est trop petit pour déclencher un changement de licence d'un projet qui voudrait l'utiliser. Si un projet non GPL envisage d'utiliser readline, je doute qu'il décide de devenir GPL juste pour ça, readline n'est pas en soi un élément de motivation suffisant. On peut imaginer que pour des lib plus importantes, genre Qt, l'auteur se pose la question du changement de licence mais pour readline, faut arrêter de rigoler.
- du coup, readline est peu utilisé. Il y a pas mal de projets avec une ligne de commande qui auraient pu facilement en tirer partie, qui ne le font pas. Je pense que readline si situe juste à la limite du truc un peu chiant à développer, dont on peut se passer mais qui est très bien à avoir. Si c'est pas facile à utiliser, il y a peu de chances que un auteur se donne la peine de redévelopper readline dans une autre licence. Dans ce sens, je pense que c'est une perte pour le logiciel libre, puisque très peu d'utilisateurs veut dire très peu de retours ou de contribution. C'est aussi de mon point de vue une perte en terme de fonctionnalité puisque pas mal de logiciels libres ou commerciaux auraient pu en bénéficier mais ne le font pas.
Si j'avais été l'auteur de readline, je l'aurai mis en BSD.
En tant qu'auteur de logiciel, j'aime que mes logiciels soient diffusés au maximum, et ça ne me pose pas de problème que certains d'entre eux soient utilisés par des entreprises, qui ne me reversent ni argent, ni contribution à mon logiciel, ni contribution au logiciel libre en général. Ca me suffit de savoir que mon logiciel leur a été utile.
Oui. Et même que finalement, ils ont dit que ça ne servait pas à grand chose et qu'ils allaient ré-intégrer leur travail dans leur équipe de base de donnée ou ailleurs mais peut-être pas dans Windows Longhorn...
J'ai toujours du mal à comprendre pourquoi ce gestionnaire de version ne reçoit pas plus de publicité.
Quand on parle de développement distribué, on mentionne en général tout de suite git mais vraiment mercurial devrait venir en premier. Pour moi, une fonctionnalité fondamentale, c'est qu'il est extrêmement bien documenté et facile à prendre en main.
En quelques secondes, il est possible de faire une interface web pour un repository mercurial, laquelle interface permet à la volée de :
- télécharger un snapshot en tar gz ou zip
- s'abonner à un flux RSS
Bien qu'il soit en python, mercurial est presqu'aussi rapide que git; Le secret ? Eviter les "disk seek". Python n'est pas une cause de lenteur dans ce cas...
Dans la maintenant célèbre video de Linus où il vante les mérites de git, il glisse aussi une petite phrase en disant que le fonctionnement de fond de mercurial est exactement le même que git et qu'on peut choisir l'un ou l'autre.
> - fournit des containers dont l'interface est plus que largement inspirée de la STL
Depuis Qt 3, tous les conteneurs Qt sont à la fois accessible avec les méthodes Qt (que je trouve mieux nommé pour ma part : first(), last(), append() ) et sont devenus compatibles avec la STL, en fournissant notamment les front(), back(), etc. La version 2 de Qt n'était pas compatible avec les algo STL du tout et était beaucoup critiquée pour cela.
Je ne suis pas d'accord pour dire que les conteneurs sont inspirés par la STL. Ils sont inspirés par les besoins des développeurs, d'où par exemple la présence d'une QString qui est autre chose qu'un vector et la présence d'une QStringList qui est autre chose qu'un vector< vector< tchar > > . Map, Hash, List, Array sont des besoins génériques des programmeurs qui n'ont été inventés ni par Qt ni par la STL.
Je ne suis donc pas d'accord avec ton affirmation même si aujourd'hui ca ne fait plus beaucoup de différence. L'approche de Trolltech a été de comprendre les besoins et de fournir une lib qui y répondait.
Les dernières versions de Qt sont de plus en plus souples, avec par exemple la possiblité de désactiver les macros signal et slots, et autres subtilités qui peuvent poser des problèmes de compabilité avec la STL (notamment avec boost::signal).
Je n'ai pas dit que Qt n'utilisait pas de template. La grosse différence entre Qt et la stdlib, c'est que les template sont très très peu visibles dans Qt. Dans 90% des cas, Qt fournit déjà des services pratiques. par exemple, tu peux itérer sur une QStringList sans template et sans pénalité en passant pourtant par des indexes.
Dans la std::lib, les template sont partout dans tous les sens. Pour faire une opération super simple, il faut se taper des template (j'ai donné un exemple plus haut).
> Contrairement à ce que certains semble prétendre, je ne crois pas que "Les fans du C++ crachent sur Qt"
Disons que Qt a été très critiqué pour ne pas avoir de conteneurs compatibles STL (ce n'est plus le cas aujourd'hui), utiliser un générateur de code séparé plutôt que d'être purement C++, pour avoir sa propre notion de typage plutôt que d'utiliser les RTTI, etc.
Un certain nombre de ces critiques ont disparu aujourd'hui, en grande partie à mon avis parce que Trolltech a fait des efforts pour rapprocher Qt de la STL.
Il n'en reste pas moins qu'on lit tous les mois des critiques de Qt parce que ce n'est pas du C++ pur.
Un truc que j'ai apprécié, c'est qu'en connaissant 10% du standard C++ et en ne connaissant rien en template, j'ai pu coder sans problème en Qt.
Pour faire des programmes en std::lib, j'ai du au contraire me plonger dans les notions de template, d'itérateurs, etc tout ca pour découvrir que le service tout simple dont j'avais besoin n'existait pas dans la lib (convertir une chaîne de caractère en minuscule). C'est d'ailleurs un autre reproche qu'on peut faire à la std::lib : sans la lib c, elle ne sert pratiquement à rien. Alors que en Qt, je n'ai encore jamais eu besoin de faire du C.
> J'ai d'ailleurs une question, comment fait-on pour trier un QVector ?
Mais on avait bien un template, j'imagine que c'est ce que tu voulais prouver.
Par contre, le QVector de Qt 3 et 4 peut être trié avec les algos de la STL.
C'est marrant, quand on critique la STL, les gens ressortent toujours l'exemple du sort. On peut en effet trier n'importe quel container avec la STL, et on peut aussi choisir son algo de tri très facilement.
Perso, dans ma vie de programmeur, j'ai encore jamais eu besoin de la flexibilité offerte par la stl pour le tri. En revanche, il ya plein de petites choses dont j'ai besion très très souvent, qui ne sont pas dans la STL mais qui sont présentes dans Qt.
Un autre truc marrant d'ailleurs, c'est que en interne, QVector convertit tout en char * (void * pour les puristes) et utilise les fonctions de la libc comme un gros bourrin. Pas si fan des template que ca les développeurs de Qt. Je pense qu'ils ont gratté quelques millisecondes de temps d'exécution avec ce type de ruse.
> les développeurs Qt sont plus conscients que vous ne semblez l'être de la richesse du C++.
Ca j'en suis persuadé. Ils connaissant toute la richesse du C++, toutes les failles des compilateurs qui soi-disant l'implémentent (rappelons par exemple que MSVC 6, un compilo très répandu ne savait pas gérer les variables déclarées à l'intérieur des for), tous les trucs pour gagner du temps, réduire la taille, etc.
Ils arrivent à transformer un langage hyper compliqué et mal documenté en un truc simple et pratique à utiliser. Plus je connais le C++ et la diversité des compilateurs et de leurs problèmes, plus j'ai de respect pour les développeurs de Trolltech.
Mouai. Le standard du C++ propose à la fois une syntaxe et une bibliothèque. Ok pour se conformer au langage (bien que quand une spec fait 1200 pages, on peut se poser la question de la logique qui préside à ce langage).
La bibliothèque standard du C++ demande un apprentissage au même titre que Qt, Gtkmm, MFC ou autre chose.
La std::lib étant plutôt pourrie et malpratique à utiliser, je ne vois pas pourquoi il faudrait préférer la std::lib par rapport à un truc pratique et rapide à utiliser. Parce que Bjarn Soustroup a réussi à le faire passer dans l'ISO ?
Les fans du C++ crachent sur Qt parce que ce n'est pas du C++ pur. [je pense au passage que la notion de pureté du langage est tout aussi débile que la propreté du code que gcc aime bien]
Je pense que ce qui fait que Qt a autant de succès malgré le fait que Qt soit écrit en C++, c'est justement que Qt simplifie énormément l'utilisation du C++, et la rend à peu près aussi simple que du python ou du java (plus simple même à mon avis pour le cas de java).
Quelques exemples en vrac :
- trouver de la doc facile à comprendre sur le C++ et ses classes outils, c'est la galère. A l'inverse, la doc de Qt est excellente.
- les conteneurs Qt sont bien foutus et bien documentés, à l'inverse du C++ qui a une approche plus mathématiquement complet mais peu intuitif. Par exemple, pour transformer une chaine de caractère en minuscule et la casser en liste de chaines, en Qt, tu fais un s.toLower().split(' ') alors que le même code en C++ classique demande la compréhension de la notion d'itérateur, de mélange entre fonctions C (tolower) et C++ (les itérateurs). La notion de string en C++ n'existe pas vraiment. Une string n'est qu'un cas particulier d'un tableau de caractère, un tableau n'étant lui-même que le cas particulier d'un conteneur qu'on peut parcourir en avant, en arrière et qu'on peux accéder par index. Tu dois donc faire un parcours de ta chaîne avec un itérateur en lui appliquant un algorithme (tolower) pour obtenir ton résultat. Ca m'a pris 2h de lecture de doc la première fois pour réussir à faire ça.
- pour faire des trucs un peu intéressants en C++, il faut vite utiliser des template qui sont difficiles à comprendre, difficiles à utiliser et qui font ramer la machine. A l'inverse Qt est vraiment facile à appréhender, grâce à son excellente doc et aux "extensions" apportées au C++.
Globalement, quand je programme en C++/Qt, je pense que j'utilise environ 10% du standard C++ et je fais plein de trucs intéressants. A l'inverse, quand je fais du C++ pur, je galère pour faire ce que je veux parce que je dois utiliser plus de C++ (disons 20 à 30%) et je peine à faire des trucs intéressants.
Dans une de mes vieilles interviews, Eirik Eng le PDG de Trolltech disait que un binding python pour Qt a peu de sens pour Trolltech, parce que Qt apporte au C++ beaucoup de services conviviaux pour les programmeurs, qui sont déjà présents à la base en python. Le besoin de Qt pour le python est donc moindre, et se limite uniquement à la partie graphique. [1]
Voilà, je pense que ca répond à la question initiale.
[1] ca n'emêche pas le binding d'être maintenu avec une très bonne qualité, mais à l'écart de Trolltech. Pour java, Trolltech en revanche héberge directement un binding java.
Euh, Eliza, c'est plus un psychanalyste qu'un psychothérapeute.
La distinction est pas forcément claire pour les non-initiés mais en gros le psychanalyste, c'est le cliché que tout le monde connait - "allongez-vous sur le divan, parlez moi de votre enfance" - où l'intervention du thérapeute est réduite et consiste à relancer doucement le client dans ses souvenirs. Ça se prête bien à Eliza puisque c'est surtout le client qui parle.
Dans la plupart des techniques de psychothérapie (et pour ma part, je ne considère pas que la psychanalyse en soi une), il y a une implication plus profonde et marquée du psychothérapeute : partage d'émotion, discussion, proposition d'un exercice mettant en jeu le corps. Bref, plein de trucs qu'on ne peut pas faire faire à Eliza et qu'on ne peut pas vraiment faire avec juste du chat.
Je vois toujours des références à du « code propre » et j'avoue que ça m'agace un peu.
On vante les mérites de gcc qui respecte au poil les standards C et C++ et qui refuse donc de compiler du « code sale ».
J'avoue que la terminologie a le don de m'énerver. Non pas que je sois un fan du code pas propre, mais pour moi, code propre et respect des standards du C++ et de C sont deux choses distinctes.
Par exemple, aujourd'hui, il n'existe aucun compilateur C++ qui supporte à 100% et sans bug le standard du C++. Donc un code qui serait « parfaitement propre » (d'après cette définition) et qui utiliserait toutes les fonctionnalités du standard ne marcherait nulle part. Trop cool !
D'un autre côté, un code qui supporterait un très large panel de compilateur et de plate-forme marchera sur plein de machines, en supportant les divers bugs et sous implémentation du standard sera « sale » mais beaucoup plus utile.
Dans cette catégorisation, il est à noter que le code de gcc est sale, tout comme le code de Linux (et la news le rappelle à juste titre).
Pour certains on a l'impression que le respect absolu des standards du C++ est un but en soi, le développement d'un logiciel n'étant qu'accessoire. Et bien non, le but c'est développer un logiciel, et le respect de certains standards, ce n'est qu'un moyen pour assurer dans certains cas une portabilité. Côté développement logiciel, c'est d'ailleurs plutôt le non-respect des standards qui assure une certaine portabilité.
Et un développeur peut avoir des trucs plus intéressants à faire (ajouter une fonctionnalité demandée par des utilisateurs, corriger un bug important) que modifier son logiciel pour qu'il compile avec la dernière version de gcc.
Bref, le respect du standard, mais il faut aussi se mettre au niveau des besoins pratiques des gens, et le respect strict à 100% du standard n'est peut-être pas le besoin le plus criant.
Après lecture détaillée du bug, on voit qu'aucun développeur Thunderbird n'a participé à la discussion. Ils ont pas l'air de considérer cette requête comme intéressante. Le bug n'est d'ailleurs pas assigné.
Pourtant, il y a des arguments vraiment importants présentés dans les commentaires : instabilité sur les gros mbox, gain en vitesse, meilleure stabilité, backup plus facile, meilleure interopérabilité avec d'autres clients mail, ...
Passage aux autotools pour faciliter l'installation ;
Ca fait des années que je n'ai pas vu les mots "autotools" et "facile" dans la même phrase, sans avoir une négation entre les deux.
On pourrait détailler, parce que autotools est quand même connu pour être un truc super compliqué et lourd, remplacé allègrement de nos jours par CMake, qmake, scons, waf, ...
Après, il faut voir que gcc est multi-plateforme. Il y a surement des plateformes où le générateur final est à la traine et donc gcc se fait exploser sur les benchs.
Ce qui est intéressant, c'est que sur une plate-forme a priori bien maintenue, intel, gcc n'est pas si à la traine que ça. Ca veut dire que globalement, il tient la route.
Pour les glycols et le paraben, tu as des liens un peu fouillés ? Quand j'avais cherché sur internet, j'avais rien trouvé de concluant sur les aspects nocifs...
La lecture de l'article est d'ailleurs édifiante sur l'attitude à l'époque de la FSF vis à vis de développement logiciel ouvert. Ils ont peut-être écrit la GPL mais leur attitude laisse presqu'à penser qu'ils auraient préféré que gcc reste un logiciel libre mais fermé dans le giron de la FSF.
Pour réussir le fork d'un projet comme gcc, il faut quand même être sacrément motivé. Les développeurs ont du sérieusement être énervés par RMS.
Avec ça, XEmacs et Hurd, on peut dire que la FSF montre quand même gravement ses limites en terme de "vision technique". C'est pas étonnant qu'un étudiant finlandais ait réussi à faire mieux qu'eux, il suffisait d'ouvrir le développement du code.
De mon côté, je me suis posé la même question. Et j'ai choisi Mercurial pour les critères suivants :
- marche sous linux et windows comme un charme
- la doc est très bien foutue, prise en main instantanée de mon côté
- doc imbitable côté git
Critères subjectifs mais importants (c'est une hérésie de croire que les humains font des choix "objectifs" ) :
- j'aime bien python
- à la lecture de la doc, j'ai bien aimé la philosophie développée par les développeurs : un outil simple et compréhensible
- a contrario, j'ai pas trop aimé l'approche de Linus : je fais le coeur, démerdez-vous avec des scripts shell et perl pour que ca ressemble à un SCM
- j'ai lu plein de fois les docs sur git, je comprends toujours pas le 10e des fonctions ni de comment ça marche. J'ai lu une fois la doc sur mercurial et j'ai tout compris, à la fois sur les fonctionnalités et sur le coeur.
- une boite s'est montée autour de mercurial. Ca veut dire qu'ils ont des contraintes, genre outil bien documenté, stabilité sur plusieurs environnements, etc. Linus au contraire a dévéloppé un truc imbitable en imposant son fonctionnement à tout le kernel. Il n'a pas besoin que git soit simple à utiliser (il est plutôt pour l'élevation des barrières d'entrée sur la contribution au kernel). C'est donc les autres qui ont du se farcir le sale boulot de rendre git approchable. Cette différence d'approche rend mercurial plus convivial.
- hg c'est plus court à taper que git
Globalement, à part le truc de windows et le fait que git marche plus vite pour des projets énormes, je pense qu'ils se valent tous les deux et que donc le choix de l'un ou de l'autre est subjectif.
Marrant, moi je suis droitier et j'ai choisi d'avoir ma souris à gauche.
La raison ? Si je pose mes deux mains sur un clavier, index sur les ergots du j et du f et que je suis centré par rapport à ton écran, je suis dans une position confortable. L'écran est centré par rapport à mes yeux, mes bras sont au repos. Dans cette position, le pavé numérique est à droite du clavier, décalé par rapport à l'écran. Si je mets la souris encore plus à droite, ça m'oblige à étirer le bras de façon démesurée et ça crée une position fatiguante.
Pour un geek qui passe des heures assis en face de son écran, ça a son importance. J'avais donc le choix entre :
- écran centré sur la médiatrice du segment GH, pavé à droite, souris encore plus à droite, position inconfortable si trop d'utilisation de la souris: bras qui fatigue, moindre précision à cause de l'extension
- clavier complet centré sur l'écran, touches GH décalées à gauche de l'écran, souris à droite du clavier. L'extension est plus faible, donc supportable. Par contre, si je tape beaucoup au clavier, je suis "de traviole" par rapport à mon écran. Mauvais pour le dos et pour la nuque.
- écran centré sur le segment GH, souris à gauche, pavé numérique à droite : bonne position du dos, peu d'extension du bras pour accéder à la souris, tête droite, je suis bien.
J'ai choisi la position 3. Et mon meilleur copain, geek lui aussi, a fait le même choix.
L'inconvénient, c'est qu'il faut devenir un peu ambidextre mais ça ne prend pas longemps. Je peux pas non plus jouer à Quake comme ça, j'ai besoin de trop de précision et de rapidité, que je n'ai pas de la main gauche.
Je suis surpris qu'aussi peu de geeks soient parvenus à cette conclusion.
Par contre, je n'inverse pas les boutons de la souris, comme ça, je peux passer de droite à gauche facilement.
Avec l'avènement des portables, sans pavé numérique décalé, j'ai remis ma souris à droite. Mais de temps en temps, je l'utilise aussi à gauche, pour le plaisir de me la péter "ambidextre".
Je suis aussi un utilisateur de vim convaincu, parce que cet éditeur est à mon sens plus ergonomique : les mains ne quittent jamais les touches du clavier, c'est plus reposant. Je n'utilise même pas les touches du curseur, trop lent et trop fatiguant, je préfère les versions vim hjkl
J'utilise également un clavier américain car celui-ce est plus adapté à la programmation. Des symboles qui servent souvent comme []{}#<>| sont bien plus accessibles sur un clavier américain. Je n'ai toujours pas vu à ce sujet de clavier dvorjak adapté à la programmation en C. A mon avis, il y aurait du boulot.
Il y a certes des choses qu'on peut reprocher à google, mais il y a quand même un certains nombre d'actes concrets de la part de google en faveur de l'ouverture, du logiciel libre, du soutien aux associations, de lutte contre la censure.
De tête comme ça :
- sponsor de pas mal de logiciels libres via les Google Summer of Code
- sponsor de l'évènement de sortie de KDE 4
- affichage des pages "vous ne pouvez pas voir le lien que vous demandez à cause d'une décision de justice" en listant explicitement le lien destinataire: je censure parce qu'on me le demande, mais pas vraiment quand même.
- offres de publicité gratuite pour les associations
- hébergement de code pour le logiciel libre
- pendant longtemps, recherche sur le net sans aucune publicité
- publicité non intrusive et clairement marquée comme telle dans les recherches.
- tous leurs services ouverts vers les autres logiciels (export de données, accès via des protocoles standards...)
J'ai l'impression qu'on reproche souvent à google d'être trop un interlocuteur unique. Sauf que cette place d'interlocuteur unique est d'une part super pratique pour les utilisateurs, d'autre part est le résultat d'un outil d'excellente qualité. Finalement, je me demande en suivant le raisonnement de certains si Google ne devrait pas renoncer à réussir si bien pour laisser la place aux autres parce que sinon, tu comprends, il est trop fort et c'est mal.
Au contraire, la clause a été ajoutée pour éviter qu'on contourne facilement l'accord. Sortir Qt 4.3.1 puis Qt 4.3.2 ne suffit pas à éviter le déclenchement de la clause BSD. Il faut sortir Qt 4.4 pour relancer les 12 mois de délai.
"of importance" est bien sur à qualifier mais c'est vraiment pour éviter une stagnation organisée.
A noter qu'à l'époque, Qt était encore sous QPL uniquement, donc faire un fork était plus compliqué. Le choix de BSD plutôt que GPL avait été fait car certains programmes licenciés en QPL uniquement auraient été incompatibles avec la GPL.
Avec le passage de Qt en GPL et GPL v3, cet accord n'a plus vraiment de raison d'être puisque n'importe qui peut raisonnablement forker Qt.
[^] # Re: A propos de la licence GPL
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 9.
[^] # Re: A propos de la licence GPL
Posté par Philippe F (site web personnel) . En réponse à la dépêche Un nouveau serveur SMTP est né : Tethys, entièrement écrit en Lua. Évalué à 8.
Je partage l'avis de l'auteur du fil de discussion. Quand je vois des projets simplistes de bibliothèques, qui choisissent la GPL, je trouve ça plutôt ridicule.
Par exemple readline ( http://tiswww.case.edu/php/chet/readline/rltop.html ). On ne peut pas utiliser la bibliothèque fournissant readline si ne fait pas un programme sous GPL. C'est un choix de l'auteur que je peux comprendre, mais je trouve que c'est plus une perte pour le logiciel libre et les logiciels commerciaux qu'autre chose. Je m'explique :
- readline est trop petit pour déclencher un changement de licence d'un projet qui voudrait l'utiliser. Si un projet non GPL envisage d'utiliser readline, je doute qu'il décide de devenir GPL juste pour ça, readline n'est pas en soi un élément de motivation suffisant. On peut imaginer que pour des lib plus importantes, genre Qt, l'auteur se pose la question du changement de licence mais pour readline, faut arrêter de rigoler.
- du coup, readline est peu utilisé. Il y a pas mal de projets avec une ligne de commande qui auraient pu facilement en tirer partie, qui ne le font pas. Je pense que readline si situe juste à la limite du truc un peu chiant à développer, dont on peut se passer mais qui est très bien à avoir. Si c'est pas facile à utiliser, il y a peu de chances que un auteur se donne la peine de redévelopper readline dans une autre licence. Dans ce sens, je pense que c'est une perte pour le logiciel libre, puisque très peu d'utilisateurs veut dire très peu de retours ou de contribution. C'est aussi de mon point de vue une perte en terme de fonctionnalité puisque pas mal de logiciels libres ou commerciaux auraient pu en bénéficier mais ne le font pas.
Si j'avais été l'auteur de readline, je l'aurai mis en BSD.
En tant qu'auteur de logiciel, j'aime que mes logiciels soient diffusés au maximum, et ça ne me pose pas de problème que certains d'entre eux soient utilisés par des entreprises, qui ne me reversent ni argent, ni contribution à mon logiciel, ni contribution au logiciel libre en général. Ca me suffit de savoir que mon logiciel leur a été utile.
[^] # Re: Bon article
Posté par Philippe F (site web personnel) . En réponse à la dépêche Les systèmes de fichiers pour disques SSD. Évalué à 4.
http://www.news.com/New-file-system-has-long-road-to-Windows(...)
# Mercurial, c'est bon, mangez-en
Posté par Philippe F (site web personnel) . En réponse à la dépêche Mercurial 1.0. Évalué à 5.
Quand on parle de développement distribué, on mentionne en général tout de suite git mais vraiment mercurial devrait venir en premier. Pour moi, une fonctionnalité fondamentale, c'est qu'il est extrêmement bien documenté et facile à prendre en main.
En quelques secondes, il est possible de faire une interface web pour un repository mercurial, laquelle interface permet à la volée de :
- télécharger un snapshot en tar gz ou zip
- s'abonner à un flux RSS
Par exemple :
http://sources.freehackers.org/hg.cgi
Bien qu'il soit en python, mercurial est presqu'aussi rapide que git; Le secret ? Eviter les "disk seek". Python n'est pas une cause de lenteur dans ce cas...
Dans la maintenant célèbre video de Linus où il vante les mérites de git, il glisse aussi une petite phrase en disant que le fonctionnement de fond de mercurial est exactement le même que git et qu'on peut choisir l'un ou l'autre.
La video côté google présentant mercurial :
http://video.google.com/videoplay?docid=-7724296011317502612(...)
Elle génère moins de buzz que celle de Linus, mais tel est le sort de Mercurial : moins de buzz mais des trucs qui marchent !
[^] # Re: gcc lave plus blanc ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 8.
Depuis Qt 3, tous les conteneurs Qt sont à la fois accessible avec les méthodes Qt (que je trouve mieux nommé pour ma part : first(), last(), append() ) et sont devenus compatibles avec la STL, en fournissant notamment les front(), back(), etc. La version 2 de Qt n'était pas compatible avec les algo STL du tout et était beaucoup critiquée pour cela.
Je ne suis pas d'accord pour dire que les conteneurs sont inspirés par la STL. Ils sont inspirés par les besoins des développeurs, d'où par exemple la présence d'une QString qui est autre chose qu'un vector et la présence d'une QStringList qui est autre chose qu'un vector< vector< tchar > > . Map, Hash, List, Array sont des besoins génériques des programmeurs qui n'ont été inventés ni par Qt ni par la STL.
Je ne suis donc pas d'accord avec ton affirmation même si aujourd'hui ca ne fait plus beaucoup de différence. L'approche de Trolltech a été de comprendre les besoins et de fournir une lib qui y répondait.
Les dernières versions de Qt sont de plus en plus souples, avec par exemple la possiblité de désactiver les macros signal et slots, et autres subtilités qui peuvent poser des problèmes de compabilité avec la STL (notamment avec boost::signal).
Je n'ai pas dit que Qt n'utilisait pas de template. La grosse différence entre Qt et la stdlib, c'est que les template sont très très peu visibles dans Qt. Dans 90% des cas, Qt fournit déjà des services pratiques. par exemple, tu peux itérer sur une QStringList sans template et sans pénalité en passant pourtant par des indexes.
Dans la std::lib, les template sont partout dans tous les sens. Pour faire une opération super simple, il faut se taper des template (j'ai donné un exemple plus haut).
> Contrairement à ce que certains semble prétendre, je ne crois pas que "Les fans du C++ crachent sur Qt"
Disons que Qt a été très critiqué pour ne pas avoir de conteneurs compatibles STL (ce n'est plus le cas aujourd'hui), utiliser un générateur de code séparé plutôt que d'être purement C++, pour avoir sa propre notion de typage plutôt que d'utiliser les RTTI, etc.
Un certain nombre de ces critiques ont disparu aujourd'hui, en grande partie à mon avis parce que Trolltech a fait des efforts pour rapprocher Qt de la STL.
Il n'en reste pas moins qu'on lit tous les mois des critiques de Qt parce que ce n'est pas du C++ pur.
Un truc que j'ai apprécié, c'est qu'en connaissant 10% du standard C++ et en ne connaissant rien en template, j'ai pu coder sans problème en Qt.
Pour faire des programmes en std::lib, j'ai du au contraire me plonger dans les notions de template, d'itérateurs, etc tout ca pour découvrir que le service tout simple dont j'avais besoin n'existait pas dans la lib (convertir une chaîne de caractère en minuscule). C'est d'ailleurs un autre reproche qu'on peut faire à la std::lib : sans la lib c, elle ne sert pratiquement à rien. Alors que en Qt, je n'ai encore jamais eu besoin de faire du C.
> J'ai d'ailleurs une question, comment fait-on pour trier un QVector ?
Dans Qt 2, tu ne pouvais pas choisir ton algo de tri :
http://doc.trolltech.com/2.3/qarray.html
Mais on avait bien un template, j'imagine que c'est ce que tu voulais prouver.
Par contre, le QVector de Qt 3 et 4 peut être trié avec les algos de la STL.
C'est marrant, quand on critique la STL, les gens ressortent toujours l'exemple du sort. On peut en effet trier n'importe quel container avec la STL, et on peut aussi choisir son algo de tri très facilement.
Perso, dans ma vie de programmeur, j'ai encore jamais eu besoin de la flexibilité offerte par la stl pour le tri. En revanche, il ya plein de petites choses dont j'ai besion très très souvent, qui ne sont pas dans la STL mais qui sont présentes dans Qt.
Un autre truc marrant d'ailleurs, c'est que en interne, QVector convertit tout en char * (void * pour les puristes) et utilise les fonctions de la libc comme un gros bourrin. Pas si fan des template que ca les développeurs de Qt. Je pense qu'ils ont gratté quelques millisecondes de temps d'exécution avec ce type de ruse.
> les développeurs Qt sont plus conscients que vous ne semblez l'être de la richesse du C++.
Ca j'en suis persuadé. Ils connaissant toute la richesse du C++, toutes les failles des compilateurs qui soi-disant l'implémentent (rappelons par exemple que MSVC 6, un compilo très répandu ne savait pas gérer les variables déclarées à l'intérieur des for), tous les trucs pour gagner du temps, réduire la taille, etc.
Ils arrivent à transformer un langage hyper compliqué et mal documenté en un truc simple et pratique à utiliser. Plus je connais le C++ et la diversité des compilateurs et de leurs problèmes, plus j'ai de respect pour les développeurs de Trolltech.
[^] # Re: gcc lave plus blanc ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 3.
La bibliothèque standard du C++ demande un apprentissage au même titre que Qt, Gtkmm, MFC ou autre chose.
La std::lib étant plutôt pourrie et malpratique à utiliser, je ne vois pas pourquoi il faudrait préférer la std::lib par rapport à un truc pratique et rapide à utiliser. Parce que Bjarn Soustroup a réussi à le faire passer dans l'ISO ?
[^] # Re: gcc lave plus blanc ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 6.
Les fans du C++ crachent sur Qt parce que ce n'est pas du C++ pur. [je pense au passage que la notion de pureté du langage est tout aussi débile que la propreté du code que gcc aime bien]
Je pense que ce qui fait que Qt a autant de succès malgré le fait que Qt soit écrit en C++, c'est justement que Qt simplifie énormément l'utilisation du C++, et la rend à peu près aussi simple que du python ou du java (plus simple même à mon avis pour le cas de java).
Quelques exemples en vrac :
- trouver de la doc facile à comprendre sur le C++ et ses classes outils, c'est la galère. A l'inverse, la doc de Qt est excellente.
- les conteneurs Qt sont bien foutus et bien documentés, à l'inverse du C++ qui a une approche plus mathématiquement complet mais peu intuitif. Par exemple, pour transformer une chaine de caractère en minuscule et la casser en liste de chaines, en Qt, tu fais un s.toLower().split(' ') alors que le même code en C++ classique demande la compréhension de la notion d'itérateur, de mélange entre fonctions C (tolower) et C++ (les itérateurs). La notion de string en C++ n'existe pas vraiment. Une string n'est qu'un cas particulier d'un tableau de caractère, un tableau n'étant lui-même que le cas particulier d'un conteneur qu'on peut parcourir en avant, en arrière et qu'on peux accéder par index. Tu dois donc faire un parcours de ta chaîne avec un itérateur en lui appliquant un algorithme (tolower) pour obtenir ton résultat. Ca m'a pris 2h de lecture de doc la première fois pour réussir à faire ça.
- pour faire des trucs un peu intéressants en C++, il faut vite utiliser des template qui sont difficiles à comprendre, difficiles à utiliser et qui font ramer la machine. A l'inverse Qt est vraiment facile à appréhender, grâce à son excellente doc et aux "extensions" apportées au C++.
Globalement, quand je programme en C++/Qt, je pense que j'utilise environ 10% du standard C++ et je fais plein de trucs intéressants. A l'inverse, quand je fais du C++ pur, je galère pour faire ce que je veux parce que je dois utiliser plus de C++ (disons 20 à 30%) et je peine à faire des trucs intéressants.
Dans une de mes vieilles interviews, Eirik Eng le PDG de Trolltech disait que un binding python pour Qt a peu de sens pour Trolltech, parce que Qt apporte au C++ beaucoup de services conviviaux pour les programmeurs, qui sont déjà présents à la base en python. Le besoin de Qt pour le python est donc moindre, et se limite uniquement à la partie graphique. [1]
Voilà, je pense que ca répond à la question initiale.
[1] ca n'emêche pas le binding d'être maintenu avec une très bonne qualité, mais à l'écart de Trolltech. Pour java, Trolltech en revanche héberge directement un binding java.
# Psychothérapeute ou psychanalyste ?
Posté par Philippe F (site web personnel) . En réponse au journal Pouvez-vous m'en dire plus sur votre mort Joseph ?. Évalué à 1.
La distinction est pas forcément claire pour les non-initiés mais en gros le psychanalyste, c'est le cliché que tout le monde connait - "allongez-vous sur le divan, parlez moi de votre enfance" - où l'intervention du thérapeute est réduite et consiste à relancer doucement le client dans ses souvenirs. Ça se prête bien à Eliza puisque c'est surtout le client qui parle.
Dans la plupart des techniques de psychothérapie (et pour ma part, je ne considère pas que la psychanalyse en soi une), il y a une implication plus profonde et marquée du psychothérapeute : partage d'émotion, discussion, proposition d'un exercice mettant en jeu le corps. Bref, plein de trucs qu'on ne peut pas faire faire à Eliza et qu'on ne peut pas vraiment faire avec juste du chat.
# gcc lave plus blanc ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 8.
On vante les mérites de gcc qui respecte au poil les standards C et C++ et qui refuse donc de compiler du « code sale ».
J'avoue que la terminologie a le don de m'énerver. Non pas que je sois un fan du code pas propre, mais pour moi, code propre et respect des standards du C++ et de C sont deux choses distinctes.
Par exemple, aujourd'hui, il n'existe aucun compilateur C++ qui supporte à 100% et sans bug le standard du C++. Donc un code qui serait « parfaitement propre » (d'après cette définition) et qui utiliserait toutes les fonctionnalités du standard ne marcherait nulle part. Trop cool !
D'un autre côté, un code qui supporterait un très large panel de compilateur et de plate-forme marchera sur plein de machines, en supportant les divers bugs et sous implémentation du standard sera « sale » mais beaucoup plus utile.
Dans cette catégorisation, il est à noter que le code de gcc est sale, tout comme le code de Linux (et la news le rappelle à juste titre).
Pour certains on a l'impression que le respect absolu des standards du C++ est un but en soi, le développement d'un logiciel n'étant qu'accessoire. Et bien non, le but c'est développer un logiciel, et le respect de certains standards, ce n'est qu'un moyen pour assurer dans certains cas une portabilité. Côté développement logiciel, c'est d'ailleurs plutôt le non-respect des standards qui assure une certaine portabilité.
Et un développeur peut avoir des trucs plus intéressants à faire (ajouter une fonctionnalité demandée par des utilisateurs, corriger un bug important) que modifier son logiciel pour qu'il compile avec la dernière version de gcc.
Bref, le respect du standard, mais il faut aussi se mettre au niveau des besoins pratiques des gens, et le respect strict à 100% du standard n'est peut-être pas le besoin le plus criant.
[^] # Re: Tests sur mac
Posté par Philippe F (site web personnel) . En réponse à la dépêche Le test Acid3 a été publié en version finale. Évalué à 6.
http://ivan.fomentgroup.org/blog/2008/03/04/acid3-and-konque(...)
[^] # Re: Eudora ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Création de l'entreprise « Mozilla Messaging ». Évalué à 3.
[^] # Re: autotools ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche VHFFS l'hébergement libre pour tous en 4.1. Évalué à 4.
[^] # Re: \o\ \o/ /o/
Posté par Philippe F (site web personnel) . En réponse à la dépêche Création de l'entreprise « Mozilla Messaging ». Évalué à 7.
Pourtant, il y a des arguments vraiment importants présentés dans les commentaires : instabilité sur les gros mbox, gain en vitesse, meilleure stabilité, backup plus facile, meilleure interopérabilité avec d'autres clients mail, ...
[^] # Re: \o\ \o/ /o/
Posté par Philippe F (site web personnel) . En réponse à la dépêche Création de l'entreprise « Mozilla Messaging ». Évalué à 10.
# autotools ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche VHFFS l'hébergement libre pour tous en 4.1. Évalué à 9.
Ca fait des années que je n'ai pas vu les mots "autotools" et "facile" dans la même phrase, sans avoir une négation entre les deux.
On pourrait détailler, parce que autotools est quand même connu pour être un truc super compliqué et lourd, remplacé allègrement de nos jours par CMake, qmake, scons, waf, ...
[^] # Re: Avis perso
Posté par Philippe F (site web personnel) . En réponse au journal Git ou Mercurial ?. Évalué à 2.
[^] # Re: Performances ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
Ce qui est intéressant, c'est que sur une plate-forme a priori bien maintenue, intel, gcc n'est pas si à la traine que ça. Ca veut dire que globalement, il tient la route.
[^] # Re: question
Posté par Philippe F (site web personnel) . En réponse au journal Le ménage libre. Évalué à 2.
[^] # Re: Les mauvaises décisions
Posté par Philippe F (site web personnel) . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 6.
Il en a eu un : egcs. Celui-ci a tellement bien marché que la branche originale de gcc a été abandonnée et que egcs est devenu le nouveau gcc:
http://en.wikipedia.org/wiki/Egcs
La lecture de l'article est d'ailleurs édifiante sur l'attitude à l'époque de la FSF vis à vis de développement logiciel ouvert. Ils ont peut-être écrit la GPL mais leur attitude laisse presqu'à penser qu'ils auraient préféré que gcc reste un logiciel libre mais fermé dans le giron de la FSF.
Pour réussir le fork d'un projet comme gcc, il faut quand même être sacrément motivé. Les développeurs ont du sérieusement être énervés par RMS.
Avec ça, XEmacs et Hurd, on peut dire que la FSF montre quand même gravement ses limites en terme de "vision technique". C'est pas étonnant qu'un étudiant finlandais ait réussi à faire mieux qu'eux, il suffisait d'ouvrir le développement du code.
[^] # Re: Idées fausses
Posté par Philippe F (site web personnel) . En réponse au journal Git ou Mercurial ?. Évalué à 5.
De mon côté, je me suis posé la même question. Et j'ai choisi Mercurial pour les critères suivants :
- marche sous linux et windows comme un charme
- la doc est très bien foutue, prise en main instantanée de mon côté
- doc imbitable côté git
Critères subjectifs mais importants (c'est une hérésie de croire que les humains font des choix "objectifs" ) :
- j'aime bien python
- à la lecture de la doc, j'ai bien aimé la philosophie développée par les développeurs : un outil simple et compréhensible
- a contrario, j'ai pas trop aimé l'approche de Linus : je fais le coeur, démerdez-vous avec des scripts shell et perl pour que ca ressemble à un SCM
- j'ai lu plein de fois les docs sur git, je comprends toujours pas le 10e des fonctions ni de comment ça marche. J'ai lu une fois la doc sur mercurial et j'ai tout compris, à la fois sur les fonctionnalités et sur le coeur.
- une boite s'est montée autour de mercurial. Ca veut dire qu'ils ont des contraintes, genre outil bien documenté, stabilité sur plusieurs environnements, etc. Linus au contraire a dévéloppé un truc imbitable en imposant son fonctionnement à tout le kernel. Il n'a pas besoin que git soit simple à utiliser (il est plutôt pour l'élevation des barrières d'entrée sur la contribution au kernel). C'est donc les autres qui ont du se farcir le sale boulot de rendre git approchable. Cette différence d'approche rend mercurial plus convivial.
- hg c'est plus court à taper que git
Globalement, à part le truc de windows et le fait que git marche plus vite pour des projets énormes, je pense qu'ils se valent tous les deux et que donc le choix de l'un ou de l'autre est subjectif.
# Profil bas
Posté par Philippe F (site web personnel) . En réponse au journal Le gouvernement US paie l'audit de projets libres (la suite). Évalué à 2.
Je suis quand même surpris que KDE soit à la traine, il m'avait semblé que les développeurs avaient justement été très réactifs au scan de converity.
Je vais voir ce qu'il en est.
[^] # Re: Gauchers unissez vous !
Posté par Philippe F (site web personnel) . En réponse au journal Gaucher, et l'informatique..... Évalué à 4.
La raison ? Si je pose mes deux mains sur un clavier, index sur les ergots du j et du f et que je suis centré par rapport à ton écran, je suis dans une position confortable. L'écran est centré par rapport à mes yeux, mes bras sont au repos. Dans cette position, le pavé numérique est à droite du clavier, décalé par rapport à l'écran. Si je mets la souris encore plus à droite, ça m'oblige à étirer le bras de façon démesurée et ça crée une position fatiguante.
Pour un geek qui passe des heures assis en face de son écran, ça a son importance. J'avais donc le choix entre :
- écran centré sur la médiatrice du segment GH, pavé à droite, souris encore plus à droite, position inconfortable si trop d'utilisation de la souris: bras qui fatigue, moindre précision à cause de l'extension
- clavier complet centré sur l'écran, touches GH décalées à gauche de l'écran, souris à droite du clavier. L'extension est plus faible, donc supportable. Par contre, si je tape beaucoup au clavier, je suis "de traviole" par rapport à mon écran. Mauvais pour le dos et pour la nuque.
- écran centré sur le segment GH, souris à gauche, pavé numérique à droite : bonne position du dos, peu d'extension du bras pour accéder à la souris, tête droite, je suis bien.
J'ai choisi la position 3. Et mon meilleur copain, geek lui aussi, a fait le même choix.
L'inconvénient, c'est qu'il faut devenir un peu ambidextre mais ça ne prend pas longemps. Je peux pas non plus jouer à Quake comme ça, j'ai besoin de trop de précision et de rapidité, que je n'ai pas de la main gauche.
Je suis surpris qu'aussi peu de geeks soient parvenus à cette conclusion.
Par contre, je n'inverse pas les boutons de la souris, comme ça, je peux passer de droite à gauche facilement.
Avec l'avènement des portables, sans pavé numérique décalé, j'ai remis ma souris à droite. Mais de temps en temps, je l'utilise aussi à gauche, pour le plaisir de me la péter "ambidextre".
Je suis aussi un utilisateur de vim convaincu, parce que cet éditeur est à mon sens plus ergonomique : les mains ne quittent jamais les touches du clavier, c'est plus reposant. Je n'utilise même pas les touches du curseur, trop lent et trop fatiguant, je préfère les versions vim hjkl
J'utilise également un clavier américain car celui-ce est plus adapté à la programmation. Des symboles qui servent souvent comme []{}#<>| sont bien plus accessibles sur un clavier américain. Je n'ai toujours pas vu à ce sujet de clavier dvorjak adapté à la programmation en C. A mon avis, il y aurait du boulot.
[^] # Re: On parie ?
Posté par Philippe F (site web personnel) . En réponse au journal Yahoo! entre en résistance ?. Évalué à 9.
De tête comme ça :
- sponsor de pas mal de logiciels libres via les Google Summer of Code
- sponsor de l'évènement de sortie de KDE 4
- affichage des pages "vous ne pouvez pas voir le lien que vous demandez à cause d'une décision de justice" en listant explicitement le lien destinataire: je censure parce qu'on me le demande, mais pas vraiment quand même.
- offres de publicité gratuite pour les associations
- hébergement de code pour le logiciel libre
- pendant longtemps, recherche sur le net sans aucune publicité
- publicité non intrusive et clairement marquée comme telle dans les recherches.
- tous leurs services ouverts vers les autres logiciels (export de données, accès via des protocoles standards...)
J'ai l'impression qu'on reproche souvent à google d'être trop un interlocuteur unique. Sauf que cette place d'interlocuteur unique est d'une part super pratique pour les utilisateurs, d'autre part est le résultat d'un outil d'excellente qualité. Finalement, je me demande en suivant le raisonnement de certains si Google ne devrait pas renoncer à réussir si bien pour laisser la place aux autres parce que sinon, tu comprends, il est trop fort et c'est mal.
# Incroyable
Posté par Philippe F (site web personnel) . En réponse au journal Intel livre les spécifications complètes des chipsets graphiques récents, sans NDA. Évalué à 10.
Du coup, ca va monterer a tous les autres fabricants de chipset que c'est possible de mettre les specs a disposition des developpeurs du libre.
[^] # Re: Lettre à la communauté
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nokia s'offre Trolltech. Évalué à 1.
"of importance" est bien sur à qualifier mais c'est vraiment pour éviter une stagnation organisée.
A noter qu'à l'époque, Qt était encore sous QPL uniquement, donc faire un fork était plus compliqué. Le choix de BSD plutôt que GPL avait été fait car certains programmes licenciés en QPL uniquement auraient été incompatibles avec la GPL.
Avec le passage de Qt en GPL et GPL v3, cet accord n'a plus vraiment de raison d'être puisque n'importe qui peut raisonnablement forker Qt.