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.
La page changera de place demain pour devenir la page finale. Les descriptions des sous-ensembles ne sont pas finales donc ne pas traduire pour l'instant.
Je sais pas d"où tu sors les problèmes de sécurité. Il est au contraire très facile de gérer la sécurité programme par programme, ou groupe de programme par groupe de programme avec une architecture Gobolinux.
Tu tous-entends aussi que tout serait simple sous une distribution normale à condition d'utiliser le gestionnaire de paquet. Dans la pratique, entre /bin, /usr/bin, /usr/lib, /usr/local/lib, /opt, on est loin d'avoir un système propre.
Mon expérience est que le gestionnaire de paquet se casse régulièrement les dents. Et si tu as le malheur de vouloir gérer un ou deux programme toi-même, ça devient vite ingérable.
Un aspect intéressant, c'est que c'est une des distribution les plus LFS compliant. Comme la partie LFS est entièrement "émulée", ils ne s'embêtent pas avec tout l'historique qu'ont les autres distributions et peuvent être 100% compatible :-)
Voilà. C'est la logique de stow poussée au niveau système.
Je mets mon programme/ma lib dans un répertoire et j'ajoute un lien / une entrée dans un index / un fichier .desktop dans une location centrale pour donner les infos.
A noter que c'est une logique utilisée dans d'autres situations. C'est comme ça que les plugins eclipse se listent auprès du système, que les .desktop sont gérés, etc.
Ils ont le code source mais il s'en servent uniquement pour faire un audit de code, vérifier qu'on n'a pas fait de connerie. Si on fait une grosse connerie, ils se jetteront dedans mais en général, ce n'est pas le cas :-)
Pour les attaques, le code source ne leur sert à rien tellement ils arrivent à récupérer d'infos par ailleurs. Ils connaissent la spécification, donc ils savent ce qu'ils cherchent. Et ils sont capables de dire à peu près ce qu'on fait à chaque instruction assembleur : manipulation d'un registre, chargement d'une donnée dans la RAM, dans l'EEPROM, dans le coprocesseur crypto, copie de buffer en RAM, etc. Quand tu sais tout ça, le code source ne sert à rien.
4 semaines, c'est peut-être court pour toi, mais quand tu payes un labo à la journée, je peux te dire que ca fait long :-)
Vu leur niveau d'expertise, on peut estimer qu'en quatre semaines, ils font un travail qui prendrait plusieurs mois à quelqu'un de moins expérimenté.
Des lib partagées entre plusieurs appli, il y en a des centaines, cf "ls /lib /usr/lib" sur ton système.
Elles sont installées dans leur propre repertoire et des liens symboliques sont mis dans /usr/lib vers lesdites librairies.
Ca permet par exemple en un tour de main de passer de la version X à la version Y : juste une mise a jour des liens à faire dans /usr/lib, je suis sur qu'il y a le petit programme qu'il faut pour faire ca bien.
C'est un peu la philosophie de je-sais-plus-quel-outil qui installait un grand jeu de lien symbolique.
Pour ma part, je trouve ca super propre et intuitif : un programme est isolé dans son repertoire, donc on n'a pas la question de savoir si il a installé des saloperies ailleurs.
Le mélange se fait uniquement au niveau système, via le jeu de lien, et pas au niveau du programme lui-même.
> C'est pour relativiser ceux qui pense que la carte à puce est inviolable...
Je pense que c'est la meilleure approximation de l'inviolable qu'on peut avoir. Pour notre dernier OS cartes, après 4 semaines d'attaque chez un labo qui est expert dans le domaine et dispose du matériel adéquat, qui a accès à toutes les specs techniques et le code source, la carte est ressortie indemne. Ca veut dire qu'avec équipement illimité, connaissances "illimitées" et temps limité à quatre semaines, des experts n'ont pas réussi à craquer cette carte. Et notre carte est en dessous (tout au moins en théorie) du niveau de sécurité exigé pour les cartes bancaires françaises.
Donc je pense vraiment que "inviolable", c'est quand même le mot qui décrit le mieux la sécurité de ces cartes à puces.
<< tous les efforts d'innovation sont dirigés vers les versions pour KDE4... qui elles mêmes ne seront pas prêtes avant KDE 4.1 pour la plupart >>.
Il est pas exclue que des applications migrent à KDE 4 et soient prêt avant la sorite de KDE 4.1 . Koffice a par exemple un cycle de sortie de version différent de celui de KDE. Après, ce serait mentir que de dire que ce sera le cas pour la majorité des applications. Il y a de fortes chances en effet qu'il faille encore patienter. Un changement aussi majeur, ça prend du temps à être réaliser.
[^] # 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.
[^] # Re: Début de news....
Posté par Philippe F (site web personnel) . En réponse au journal KDE4. Évalué à 2.
http://www.kde.org/announcements/visual-guide_4.0/index.php
La page changera de place demain pour devenir la page finale. Les descriptions des sous-ensembles ne sont pas finales donc ne pas traduire pour l'instant.
Tout ceci doit rester non publié pour l'instant.
[^] # Re: Fausse bonne idée
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gobolinux 014. Évalué à 1.
Tu tous-entends aussi que tout serait simple sous une distribution normale à condition d'utiliser le gestionnaire de paquet. Dans la pratique, entre /bin, /usr/bin, /usr/lib, /usr/local/lib, /opt, on est loin d'avoir un système propre.
Mon expérience est que le gestionnaire de paquet se casse régulièrement les dents. Et si tu as le malheur de vouloir gérer un ou deux programme toi-même, ça devient vite ingérable.
[^] # Re: Plus de sens ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gobolinux 014. Évalué à 4.
[^] # Re: Bibliothèques partagées ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gobolinux 014. Évalué à 1.
Je mets mon programme/ma lib dans un répertoire et j'ajoute un lien / une entrée dans un index / un fichier .desktop dans une location centrale pour donner les infos.
A noter que c'est une logique utilisée dans d'autres situations. C'est comme ça que les plugins eclipse se listent auprès du système, que les .desktop sont gérés, etc.
[^] # Re: étonnant
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gobolinux 014. Évalué à 1.
[^] # Re: FreeRunner et vitesse CPU
Posté par Philippe F (site web personnel) . En réponse à la dépêche LiPS 1.0, Bazaar 1.0 et OpenMoko Neo FreeRunner. Évalué à 0.
[^] # Re: DES?
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
Pour les attaques, le code source ne leur sert à rien tellement ils arrivent à récupérer d'infos par ailleurs. Ils connaissent la spécification, donc ils savent ce qu'ils cherchent. Et ils sont capables de dire à peu près ce qu'on fait à chaque instruction assembleur : manipulation d'un registre, chargement d'une donnée dans la RAM, dans l'EEPROM, dans le coprocesseur crypto, copie de buffer en RAM, etc. Quand tu sais tout ça, le code source ne sert à rien.
4 semaines, c'est peut-être court pour toi, mais quand tu payes un labo à la journée, je peux te dire que ca fait long :-)
Vu leur niveau d'expertise, on peut estimer qu'en quatre semaines, ils font un travail qui prendrait plusieurs mois à quelqu'un de moins expérimenté.
[^] # Re: Bibliothèques partagées ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gobolinux 014. Évalué à 4.
Elles sont installées dans leur propre repertoire et des liens symboliques sont mis dans /usr/lib vers lesdites librairies.
Ca permet par exemple en un tour de main de passer de la version X à la version Y : juste une mise a jour des liens à faire dans /usr/lib, je suis sur qu'il y a le petit programme qu'il faut pour faire ca bien.
C'est un peu la philosophie de je-sais-plus-quel-outil qui installait un grand jeu de lien symbolique.
Pour ma part, je trouve ca super propre et intuitif : un programme est isolé dans son repertoire, donc on n'a pas la question de savoir si il a installé des saloperies ailleurs.
Le mélange se fait uniquement au niveau système, via le jeu de lien, et pas au niveau du programme lui-même.
[^] # Re: DES?
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
Je pense que c'est la meilleure approximation de l'inviolable qu'on peut avoir. Pour notre dernier OS cartes, après 4 semaines d'attaque chez un labo qui est expert dans le domaine et dispose du matériel adéquat, qui a accès à toutes les specs techniques et le code source, la carte est ressortie indemne. Ca veut dire qu'avec équipement illimité, connaissances "illimitées" et temps limité à quatre semaines, des experts n'ont pas réussi à craquer cette carte. Et notre carte est en dessous (tout au moins en théorie) du niveau de sécurité exigé pour les cartes bancaires françaises.
Donc je pense vraiment que "inviolable", c'est quand même le mot qui décrit le mieux la sécurité de ces cartes à puces.
[^] # Re: Concrètement
Posté par Philippe F (site web personnel) . En réponse au journal KDE 4.0.0 is out \o/. Évalué à 1.
Il est pas exclue que des applications migrent à KDE 4 et soient prêt avant la sorite de KDE 4.1 . Koffice a par exemple un cycle de sortie de version différent de celui de KDE. Après, ce serait mentir que de dire que ce sera le cas pour la majorité des applications. Il y a de fortes chances en effet qu'il faille encore patienter. Un changement aussi majeur, ça prend du temps à être réaliser.