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.
Il y a vraiment des infos intéressantes dans cet article. Citons :
Öistämö a promis que Nokia "contribuerait activement à la communauté Open Source, et en particulier KDE", et "continuerait à investir dans Qt, en ajoutant des de nouvelles fonctionnalités graphiques avancées". Il a aussi assuré que une des motivations principales de l'acquisition était les "talents" de Trolltech et qu'il n'y avait pas de "plans pour réduire leurs équipes".
[...]
Chambe-Eng a dit que la décision de Nokia de garder Gnome pour leurs terminaux Linux "était tout à fait justifiée". "Ilso ont une équipe interne qui fait cela depuis longtemps. [...] Il est possible d'utiliser Qt avec Gnome. Très peu de gens sont conscients du fait que KDE et Gnome sont en fait très compatibles".
[...]
Chambe-Eng a ajouté que la décision de Nokia de maintenir le double modèle de licence et de continuer à participer à la communauté open source a vraiment été un élément clé de l'acquisition.
Une des conséquences les plus intéressantes est que Nokia n'a pas besoin de faire tourner Trolltech en tant que Centre de Profit, bien qu'ils le fassent peut-être. Nokia gagne suffisamment en 2h30 pour couvrir les pertes annuelles de Trolltech.
Nokia a indiqué que l'interêt de racheter Trolltech, c'est la quadruple plate-forme. Donc d'après les informations disponibles, il est peu probable qu'ils négligent un la partie desktop de Qt.
Pour les vraiment inquiets, on peut rappeler qu'il existe une fondation FreeQt entre Trolltech et KDE eV, dont les termes stipulent que si Trolltech cesse de sortir une version de Qt/X11 en GPL pendant deux ans, Qt passe automatiquement en licence BSD. Des discussions sont en cours pour étendre cet engagement aux nouvelles plate-formes supportées par KDE.
En ce qui me concerne, je suis un petit peu inquiet, mais l'engagement de Trolltech, des ses employés et de son management derrière l'open source n'a jamais failli. C'est une culture qui est présente et c'est une des raisons qui motivent l'achat de Nokia. Si les employés et les dirigeants de Trolltech font confiance à Nokia, qui suis-je pour leur dire qu'ils ont tort ? Ils ont certainement plus d'informations que moi.
Lors de la dernière interview que j'ai réalisé, Eirik Eng disait qu'ils ont été longtemps bénéficiaires, mais qu'ils ont décidé d'investir massivement, d'où à l'époque une levée de fond et des déficits prévus sur plusieurs années le temps que les investissements se rentabilisent. Ils étaient visiblement encore dans cette zone.
<< Je me demande juste si ces réussites sont un succès du logiel libre ou de la part propriétaire de l'activité de ses sociétés. >>
Pourquoi ça ne devrait être que l'un ou que l'autre ? De mon point de vue, ces succès (car une vente d'entreprise est en général un succès) sont dus à un bon mélange entre libre et proprio.
Tout libre, tu n'as pas assez de verrou sur ton client pour gagner de l'argent. Mais avec beaucoup de libre et un produit, tu bénéficie d'un bon retour de la communauté, tout en te gardant une part de revenu sur l'activité propriétaire. Après, il faut trouver la bonne combinaison.
Je pense pas que ce soit deux services différents qui veuillent acquérir Trolltech d'une part et travailler avec Gtk d'autre part. La press release parle en effet de convergence mobile-desktop, ce qui était bien l'objet du projet maemo.
Moi j'imagine en partie une raison technique. Pour réaliser maemo, Nokia a du investir de la main d'oeuvre pour l'adapter à son téléphone : il y a eu webkit-gtk, puis d'autres modifs à faire sur Gtk. Dans le cas de Qt, il y a déjà des ingénieurs qui font ça depuis des années. On peut presque voir ca comme une acquisition de main d'oeuvre.
En tout cas, la nouvelle ne me fait pas super plaisir. Je suis moins tranquille avec Qt possedé par Nokia que par Trolltech.
On note en tout cas qu'on est dans une phase de concentration. Les gros acquiert des acteurs importants et reconnus du libre.
<< Je comprend qu'on ne soit pas familier avec ce genre de chose et qu'on préfère avoir des fonctions membres pour tous les usages mais ce n'est pas la philosophie de la STL. En même temps libre à chacun de ne pas l'utiliser mais c'est souvent plus à cause de la trop grande généricité qu'à cause d'une vrai impossibilité.>>
C'est bien la le problème. La STL ne répond pas a des besoins pratiques. C'est une belle abstraction en générale, mais des qu'on veut l'utiliser concrètement, c'est lourd. Ca me fait plus penser à un concept mathématique que à une bibliothèque destinée à la programmation.
Je fais la comparaison avec la QTL (Qt Template Library) qui au contraire est très orientée vers un usage quotidien et contient en dur les fonctions dont tu as besoin très souvent, et contient facilement accessible des fonctions moins usitées. Au passage, la QTL est compatible avec les iterateurs de la STL donc tu peux mixer les deux allègrement. Et certaines versions de la QTL sont plus rapides pour un usage "standard".
Globalement, la standardisation du C++ prend la direction d'un langage extrêmement complexe avec du branlage de mouche à différentes étapes (par exemple, il faut lire un ou deux bouquins pour apprendre à gérer correctement les exceptions générées à l'intérieur d'un constructeur). Au final, très peu de gens comprennent réellement le C++ (et je suis heureux d'en être - je veux dire, de ceux qui ne comprennent pas). La plupart des gens utilisent les fonctionnalités de base, on pourrait dire les fonctionnalités qu'on retrouve dans Java.
Faire du template meta-programming, typiquement, c'est un bel exercice intellectuel et boost ou la stl montre qu'on peut faire des choses chiadées avec. Sauf que :
- seul 1 programmeur sur 100 sera capable de comprendre le code
- très peu de compilateurs sont suffisamment compatibles pour fonctionner correctement avec du template meta-programming
- on s'aperçoit que dans d'autres langages, on fait tout aussi bien tout en restant lisible par les autres programmeurs. Au hasard, des programmes qu'on ne peut pas écrire autrement qu'en faisant du template meta-programming en C++ s'écrivent très simplement en python.
Finalement, je ne comprends pas la finalité de la direction actuelle de ce langage. Soit c'est pour faire des trucs originaux et nouveaux, mais dans ce cas, autant se tourner vers des langages ou on a de la latitude pour ajouter des nouveau concepts : eiffel, OCaml, Lisp, Lissac, ... Soit c'est pour faire un langage pratique, mais dans ce cas, la complexité de la gestion des exceptions ou de la programmation par template, ou bien les manques pratiques de la STL ne sont pas justifiés.
Concernant les strings, la STL fait la même erreur que le C : elle les traite strictement comme un tableau de caractères. Certe, elle fait ça mieux que le C, puisque tu peux manipuler des tchar mais au final, il lui manque toujours des fonctions pratiques et communes à toute lib string qui se respecte. Au hasard :
- découpage d'une string en liste de string avec un token
- recollage d'une liste de string avec un token
- mise en majuscule, mise en minuscule
- conversion UTF8, latin1, UCS16
Quand tu manipule des strings t'as souvent besoin de faire ça et même en général un peu plus. Mais en STL, en dehors de pouvoir choisir ton algorithme de tri générique de ta chaîne de caractères, t'es super limité. Et honnêtement, trier des chaînes, je le fais moins souvent que les découper en fonction d'un token.
Du C++ pur, pas vraiment. Certains voient d'ailleurs ça comme un gros inconvénient, alors que d'autres (dont je suis) voient ça comme un avantage.
Un objet C++ héritant de QObject et bénéficie grâce au travail du moc :
- des signaux et des slots
- de l'introspection
- de signaux très pratiques du genre aboutToBeDeleted() et deleted()
- d'une gestion relativement automatique de la destruction
- de la notion de propriété (attributs qu'on peut régler sur un objet)
Ca fait quand même pas mal de choses. Tout ça pour le prix d'une petite phase de compilation supplémentaire, gérée par le compilateur moc.
Ces fonctionnalités en plus sont ce qui rend Qt plus facile à utiliser qu'un framework C++ standard.
C'est marrant, autant il était claire pour moi que des distributions dérivées auraient une longue existence, autant je suis toujours ébahi de voir à quel point l'écosystème des distributions est actif. Il y a tous les 3-4 ans une nouvelle distrib populaire et pas mal foutue.
Gérer la croissance d'une distrib et maintenir la qualité, c'est un challenge énorme. Apparamment, tout le monde n'est en pas capable.
En tout cas, chapeau pour ceux qui entreprennent une telle tâche. Même si gentoo meurt doucement, elle a eu un beau succès.
<< Donc une appli comme wengo aurait probablement couté moins cher à ebay que skype qu'ils ont surpayé. >>
Parfois, la naïveté des gens ici me fait sourire. Je pense que beaucoup de personnes ici n'ont pas eu beaucoup d'exposition à ce que c'est que de faire gagner de l'argent à une entreprise, la rendre visible sur un marché, compétitive, de donner une direction stratégique viable, etc.
C'est sur que ebay aurait payé OpenWengo beaucoup moins cher que skype. Même à mon avis, ils auraient pu l'avoir pour le capital social, c'est à dire quelques cacahouètes.
Mais ca ne lui aurait strictement rien rapporté. L'atout de skype, c'est son nombre d'utilisateurs. Et là, on change de galaxie entre OpenWengo et Skype.
<< Dans la minute où ebay trouve un moyen de faire de l'argent avec skype, quelqu'un se rendra compte qu'il peut proposer la même chose sans dépenser 4 milliards comme ebay. >>
Honnêtement, ebay en a rien à foutre de faire de la téléphonie sur IP. C'est pour ça que j'ai parlé de naïveté. Tu penses que parce que skype et openwengo rendent le même service technique, ils présentent le même intérêt commercial.
C'est simple de faire de l'argent avec skype, il suffit de trouver un moyen de tirer partie de l'immense base d'utilisateurs. Imagine si chaque utilisateur de skype paye un euro de plus pour un service quelconque. Combien ca peut rapporter à ebay ? A mon avis, plus de 4 millions. Et tiens donc, l'autre jour sur skype, j'ai reçu la proposition d'un service pour me créer un avatar graphique. Et ça coûtait ? Un euro.
Note qu'il y a des gens qui ont compris ta proposition, mais pas comme tu l'imaginais. Il y a des gens qui ont trouvé le même moyen que skype de faire de l'argent : il ont attiré des millions d'utilisateurs. On peut citer facebook par exemple dont la valorisation est proche de celle de skype si je me souviens bien.
Quand à l'interdiction de skype dans les administrations, il faudrait voir dans quelle mesure c'est appliqué. Dans mon entreprise qui est pourtant super parano, skype est utilisé partout. Pourquoi ? Parce que avec zéro configuration, ça marche. C'est comme ça qu'on gagne des utilisateurs, et qu'au final, on est valorisé à 4 millions d'euro.
On utilise ca au boulot et c'est un plaisir en ce qui me concerne. On peut faire des workflow clairs, c'est simple a installer, simple a prendre en main et il fait tout ce dont j'ai besoin.
Il y a des plugins pour faire de l'integration avec des SCM et pour faire des jolis graphes.
[^] # 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.
[^] # Re: Lettre à la communauté
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nokia s'offre Trolltech. Évalué à 5.
http://news.zdnet.co.uk/software/0,1000000121,39292448,00.ht(...)
Il y a vraiment des infos intéressantes dans cet article. Citons :
Sinon, je trouve les commentaires de Bero et Zack Rusin plutôt bien écrit :
http://dot.kde.org/1201517986/1201522216/1201540844/
http://dot.kde.org/1201517986/1201518746/1201519722/12015203(...)
http://dot.kde.org/1201517986/1201522216/1201523409/
L'analyse chiffrée de Scott Wheeler est aussi intéressante :
http://www.kdedevelopers.org/blog/72
Citons :
[^] # Re: Qtopia
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nokia s'offre Trolltech. Évalué à 8.
# Lettre à la communauté
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nokia s'offre Trolltech. Évalué à 10.
http://trolltech.com/28012008/28012008
Avec notamment :
- La possibilité d'écouter la conférence de presse
- Une lettre ouverte à la communauté Open Source : http://trolltech.com/28012008/28012008-letter
- Une lettre aux clients de Trolltech : http://trolltech.com/28012008/customer-letter
- Une faq sur le sujet : http://trolltech.com/28012008/28012008-faq
La dépeche gagnerait aussi à signaler que Trolltech maintient son engagement vers l'open source et vers le projet KDE notamment.
Eirik Eng a posté un message sur kde-core-devel : http://lists.kde.org/?l=kde-core-devel&m=120150574710891(...)
On peut citer quelques blogs qui traitent du sujet :
- l'infatigable Aaron J. Seigo, président de KDE eV : http://aseigo.blogspot.com/2008/01/nokia-and-trolltech.html
- Lars Knoll, développeur KDE de longue date et employé de Trolltech : http://labs.trolltech.com/blogs/2008/01/28/nokia-to-acquire-(...)
Pour les vraiment inquiets, on peut rappeler qu'il existe une fondation FreeQt entre Trolltech et KDE eV, dont les termes stipulent que si Trolltech cesse de sortir une version de Qt/X11 en GPL pendant deux ans, Qt passe automatiquement en licence BSD. Des discussions sont en cours pour étendre cet engagement aux nouvelles plate-formes supportées par KDE.
En ce qui me concerne, je suis un petit peu inquiet, mais l'engagement de Trolltech, des ses employés et de son management derrière l'open source n'a jamais failli. C'est une culture qui est présente et c'est une des raisons qui motivent l'achat de Nokia. Si les employés et les dirigeants de Trolltech font confiance à Nokia, qui suis-je pour leur dire qu'ils ont tort ? Ils ont certainement plus d'informations que moi.
[^] # Re: info interessante
Posté par Philippe F (site web personnel) . En réponse au journal Nokia pourrait acquérir Trolltech. Évalué à 5.
[^] # Re: Ca y est, c'est fait :
Posté par Philippe F (site web personnel) . En réponse au journal Nokia pourrait acquérir Trolltech. Évalué à 3.
Il faut pas en déduire non plus que les employés ont pour l'instant refusé l'offre. Ils sont en cours de consultation via cette annonce de presse.
C'est au passage une bonne garantie sur le deal : il doit respecter les empoyés, sinon il ne marchera pas.
[^] # Re: TroolTech et MysqlAB
Posté par Philippe F (site web personnel) . En réponse au journal Nokia pourrait acquérir Trolltech. Évalué à 6.
Pourquoi ça ne devrait être que l'un ou que l'autre ? De mon point de vue, ces succès (car une vente d'entreprise est en général un succès) sont dus à un bon mélange entre libre et proprio.
Tout libre, tu n'as pas assez de verrou sur ton client pour gagner de l'argent. Mais avec beaucoup de libre et un produit, tu bénéficie d'un bon retour de la communauté, tout en te gardant une part de revenu sur l'activité propriétaire. Après, il faut trouver la bonne combinaison.
[^] # Re: Qt everywhere
Posté par Philippe F (site web personnel) . En réponse au journal Nokia pourrait acquérir Trolltech. Évalué à 4.
La lettre à la communauté Open Source est plutôt rassurante.
[^] # Re: N800
Posté par Philippe F (site web personnel) . En réponse au journal Nokia pourrait acquérir Trolltech. Évalué à 8.
Moi j'imagine en partie une raison technique. Pour réaliser maemo, Nokia a du investir de la main d'oeuvre pour l'adapter à son téléphone : il y a eu webkit-gtk, puis d'autres modifs à faire sur Gtk. Dans le cas de Qt, il y a déjà des ingénieurs qui font ça depuis des années. On peut presque voir ca comme une acquisition de main d'oeuvre.
En tout cas, la nouvelle ne me fait pas super plaisir. Je suis moins tranquille avec Qt possedé par Nokia que par Trolltech.
On note en tout cas qu'on est dans une phase de concentration. Les gros acquiert des acteurs importants et reconnus du libre.
[^] # Re: langage de haut niveau?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 2.
Dans pypy en revanche, le choix du GC est entièrement configurable. En fait, dans pypi, tout est configurable.
[^] # Re: C & Cie
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 6.
C'est bien la le problème. La STL ne répond pas a des besoins pratiques. C'est une belle abstraction en générale, mais des qu'on veut l'utiliser concrètement, c'est lourd. Ca me fait plus penser à un concept mathématique que à une bibliothèque destinée à la programmation.
Je fais la comparaison avec la QTL (Qt Template Library) qui au contraire est très orientée vers un usage quotidien et contient en dur les fonctions dont tu as besoin très souvent, et contient facilement accessible des fonctions moins usitées. Au passage, la QTL est compatible avec les iterateurs de la STL donc tu peux mixer les deux allègrement. Et certaines versions de la QTL sont plus rapides pour un usage "standard".
Globalement, la standardisation du C++ prend la direction d'un langage extrêmement complexe avec du branlage de mouche à différentes étapes (par exemple, il faut lire un ou deux bouquins pour apprendre à gérer correctement les exceptions générées à l'intérieur d'un constructeur). Au final, très peu de gens comprennent réellement le C++ (et je suis heureux d'en être - je veux dire, de ceux qui ne comprennent pas). La plupart des gens utilisent les fonctionnalités de base, on pourrait dire les fonctionnalités qu'on retrouve dans Java.
Faire du template meta-programming, typiquement, c'est un bel exercice intellectuel et boost ou la stl montre qu'on peut faire des choses chiadées avec. Sauf que :
- seul 1 programmeur sur 100 sera capable de comprendre le code
- très peu de compilateurs sont suffisamment compatibles pour fonctionner correctement avec du template meta-programming
- on s'aperçoit que dans d'autres langages, on fait tout aussi bien tout en restant lisible par les autres programmeurs. Au hasard, des programmes qu'on ne peut pas écrire autrement qu'en faisant du template meta-programming en C++ s'écrivent très simplement en python.
Finalement, je ne comprends pas la finalité de la direction actuelle de ce langage. Soit c'est pour faire des trucs originaux et nouveaux, mais dans ce cas, autant se tourner vers des langages ou on a de la latitude pour ajouter des nouveau concepts : eiffel, OCaml, Lisp, Lissac, ... Soit c'est pour faire un langage pratique, mais dans ce cas, la complexité de la gestion des exceptions ou de la programmation par template, ou bien les manques pratiques de la STL ne sont pas justifiés.
[^] # Re: C & Cie
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 5.
- découpage d'une string en liste de string avec un token
- recollage d'une liste de string avec un token
- mise en majuscule, mise en minuscule
- conversion UTF8, latin1, UCS16
Quand tu manipule des strings t'as souvent besoin de faire ça et même en général un peu plus. Mais en STL, en dehors de pouvoir choisir ton algorithme de tri générique de ta chaîne de caractères, t'es super limité. Et honnêtement, trier des chaînes, je le fais moins souvent que les découper en fonction d'un token.
[^] # Re: C & Cie
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Vala 0.1.6. Évalué à 5.
Un objet C++ héritant de QObject et bénéficie grâce au travail du moc :
- des signaux et des slots
- de l'introspection
- de signaux très pratiques du genre aboutToBeDeleted() et deleted()
- d'une gestion relativement automatique de la destruction
- de la notion de propriété (attributs qu'on peut régler sur un objet)
Ca fait quand même pas mal de choses. Tout ça pour le prix d'une petite phase de compilation supplémentaire, gérée par le compilateur moc.
Ces fonctionnalités en plus sont ce qui rend Qt plus facile à utiliser qu'un framework C++ standard.
[^] # Re: Pas une grande surprise
Posté par Philippe F (site web personnel) . En réponse au journal Gentoo file un mauvais coton. Évalué à 2.
C'est marrant, autant il était claire pour moi que des distributions dérivées auraient une longue existence, autant je suis toujours ébahi de voir à quel point l'écosystème des distributions est actif. Il y a tous les 3-4 ans une nouvelle distrib populaire et pas mal foutue.
Gérer la croissance d'une distrib et maintenir la qualité, c'est un challenge énorme. Apparamment, tout le monde n'est en pas capable.
En tout cas, chapeau pour ceux qui entreprennent une telle tâche. Même si gentoo meurt doucement, elle a eu un beau succès.
[^] # Re: Il faut bien manger
Posté par Philippe F (site web personnel) . En réponse au journal OpenWengo dans les choux !. Évalué à 10.
Parfois, la naïveté des gens ici me fait sourire. Je pense que beaucoup de personnes ici n'ont pas eu beaucoup d'exposition à ce que c'est que de faire gagner de l'argent à une entreprise, la rendre visible sur un marché, compétitive, de donner une direction stratégique viable, etc.
C'est sur que ebay aurait payé OpenWengo beaucoup moins cher que skype. Même à mon avis, ils auraient pu l'avoir pour le capital social, c'est à dire quelques cacahouètes.
Mais ca ne lui aurait strictement rien rapporté. L'atout de skype, c'est son nombre d'utilisateurs. Et là, on change de galaxie entre OpenWengo et Skype.
<< Dans la minute où ebay trouve un moyen de faire de l'argent avec skype, quelqu'un se rendra compte qu'il peut proposer la même chose sans dépenser 4 milliards comme ebay. >>
Honnêtement, ebay en a rien à foutre de faire de la téléphonie sur IP. C'est pour ça que j'ai parlé de naïveté. Tu penses que parce que skype et openwengo rendent le même service technique, ils présentent le même intérêt commercial.
C'est simple de faire de l'argent avec skype, il suffit de trouver un moyen de tirer partie de l'immense base d'utilisateurs. Imagine si chaque utilisateur de skype paye un euro de plus pour un service quelconque. Combien ca peut rapporter à ebay ? A mon avis, plus de 4 millions. Et tiens donc, l'autre jour sur skype, j'ai reçu la proposition d'un service pour me créer un avatar graphique. Et ça coûtait ? Un euro.
Note qu'il y a des gens qui ont compris ta proposition, mais pas comme tu l'imaginais. Il y a des gens qui ont trouvé le même moyen que skype de faire de l'argent : il ont attiré des millions d'utilisateurs. On peut citer facebook par exemple dont la valorisation est proche de celle de skype si je me souviens bien.
Quand à l'interdiction de skype dans les administrations, il faudrait voir dans quelle mesure c'est appliqué. Dans mon entreprise qui est pourtant super parano, skype est utilisé partout. Pourquoi ? Parce que avec zéro configuration, ça marche. C'est comme ça qu'on gagne des utilisateurs, et qu'au final, on est valorisé à 4 millions d'euro.
[^] # Re: mantis
Posté par Philippe F (site web personnel) . En réponse au journal Nan mais quoi comme gestionnaire de bugs ?. Évalué à 2.
On utilise ca au boulot et c'est un plaisir en ce qui me concerne. On peut faire des workflow clairs, c'est simple a installer, simple a prendre en main et il fait tout ce dont j'ai besoin.
Il y a des plugins pour faire de l'integration avec des SCM et pour faire des jolis graphes.