Planet Ubuntu Francophone - Mark shuttleworth

Canonical rentable. C’est pour bientôt

Cedynamix — Sun, 02 Nov 2008 09:51:58 +0100

Ubuntu, à la différence de certains ces concurrents dans le secteur des distributions Linux, est disponible gratuitement et dans toutes ses versions. Cette nouvelle donne a affecté le marché de Red Hat et SuSE, mais ne s’est pas encore révélée être rentable d’un point de vue financier pour l’entreprise qui la soutient, je parle bien-sûr de Canonical. Mark Shuttleworth, qui a fait fortune en vendant sa société Thawte à Verisign pour 575 millions de dollars, a déclaré récemment qu’il continuerait de soutenir financièrement Canonical pendant encore quelque temps.

“Je n’ai pas de problème pour financer l’entreprise encore 3 ou 5 ans”, a-t-il déclaré dans une conférence, “Canonical n’a pas encore atteint son équilibre économique, mais notre offre reste très appropriée pour ceux qui souhaitent réduire leurs coûts.”

Pour Shuttleworth, l’arrivée de cet équilibre et des futures bénéfices qui vont avec, n’est plus qu’une question de temps. Canonical doit continuer à investir dans des domaines qu’il juge importants pour le système d’exploitation plutôt que d’en réduire le développement et de s’orienter vers une plus grande rentabilité.

Canonical base ses activités principalement sur la vente de contrat de support et de services, tant pour les particuliers que pour les entreprises qui ont besoin de développer leur expérience sur les systèmes basés sur Linux.

Shuttleworth a déclaré : “Je ne pense pas que Canonical puisse faire des profits grâce à la vente de la distribution. Nous ne voulons pas nous essayer sur cette voie. Nous portons notre attention sur les modèles d’affaires axés sur les services. Je reste convaincu que le chemin à prendre pour générer du profit avec une entreprise basée sur Linux est de mettre l’accent sur le service”.

Mais Shuttleworth ressent la nécessité d’accélérer le processus de rentabilité, pour éviter que Canonical s’enlise dans la paresse et finisse par se dire plus souvent qu’il ne faut “Mark va financer ce dont nous avons besoin.” Canonical devra au plus tôt s’autofinancer, plutôt que de s’appuyer sur le portefeuille de Mark et transformer un beau rêve en une réalité concrète.

Ubuntu 9.04 Jaunty Jackalope

Cedynamix — Tue, 09 Sep 2008 21:35:37 +0200

Mark Shuttleworth, fondateur de Canonical (la société qui sponsorise Ubuntu) a écrit un petit mail sur la liste des développeurs dans lequel il annonce entre autres choses, le nom de code de la version qui succédera à Ubuntu Intrepid Ibex et elle se nomme Ubuntu Jaunty Jackalope.

Jaunty Jackalope (9.10) sera publié en avril 2009 et sera le principal objectif des efforts des développeurs de novembre à avril de l’année prochaine.

Le Ubuntu Developer Summit (UDS) qui à son terme définira les nouveautés et les orientations de cette nouvelle version se déroulera à Mountain View du 8 au 12 décembre 2008. Mais Shuttleworth a déjà mis en avant quelques-uns des objectifs que devra atteindre Jaunty Jackalope dont une réduction du temps nécessaire pour redémarrer suite à une mise en vieille ou une hibernation et résorber au maximum les frontières qui séparent les applications Web des applications de bureau.

Pour les plus curieux d’entre vous, la signification Jaunty Jackalope, jaunty signifie joyeux ou occasionnels et Jackalope est un animal mythologique, un mélange de lièvre et le cerf ou d’antilope.

En tout cas, s’il y a une chose de sûr, c’est que ce nom et bien il n’est pas beau. En espérant que le plumage ne reflétera pas le ramage comme on dit. Cela n’est bien sûr que mon avis et le vôtre c’est quoi ? Allez un petit sondage pour savoir.

SONDAGE

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Regroupement économique et coordination de la production de Logiciels Libres

Bernard Opic — Thu, 14 Aug 2008 21:42:52 +0200

Traduction française de l’article “Economic clustering and Free Software release coordination“.
Auteur : Mark Shuttleworth - Traducteur : Bernard Opic

—

J’ai eu l’occasion de faire une présentation à Linux Symposium ce vendredi et j’ai décrit mon espoir que nous puissions améliorer la coordination et le rythme de toute la couche de logiciel libre. J’ai essayé de présenter à la fois les bénéfices évidents et les controverses que l’idée à fait jaillir.

Ensuite, quelques personnes sont montées pour en parler un peu plus, généralement avec un retour positif.

Par exemple, Christophe Curtis a envoyé un mail pour dire que l’idée du regroupement économique dans l’industrie automobile allait bien plus loin que la répartition géographique des vendeurs de voitures. Il écrit :

Premièrement, chaque constructeur de voiture sort ses nouveaux modèles en même temps. Chaque constructeur de voiture a des produits similaires – économique, berline, camionnette. Ils se copient abondamment les uns les autres. Au final, ils optent tous pour un certain profil – ceintures de sécurité, pares-chocs, airbags, freins anti-blocage. Ensuite ils rivalisent férocement (OnStar chez GM ; Microsoft Sync chez Ford) et les gens restent fidèles à la marque. Cela ne va pas être différent dans le monde Linux. Encore mieux, des relations comme Debian->Ubuntu correspondent à des relations comme Toyota->Lexus chez les fabricants de voitures.

Je suis totalement en phase avec lui. Les distributions Linux et les fabricants de voitures sont très semblables : nous vendons des produits qui touchent le public selon le même principe (il y a des spécialistes de niche en temps-réel, en systèmes embarqués ou sur des marchés régionaux) avec une gamme similaire (ordinateur de bureau, station de travail, serveur, mobile) et nous utilisons de nombreux composants identiques tout comme l’industrie automobile a recours à des fournisseurs communs. Cette similitude et la coordination bénéficient à l’industrie automobile et néanmoins les marques et les produits conservent leur identité.

Faisons un petit test de mémoire. Pouvez-vous citer, la dernière version entreprise majeure de votre distribution favorite, les numéros de versions majeurs du noyau, de gcc, de X, de GNOME, de KDE, de OpenOffice.org ou de Mozilla qui étaient livrés ? Et pouvez-vous dire si ces numéros de versions majeurs étaient les mêmes ou différents de ceux des versions entreprise de Ubuntu, SLES, Debian ou RHEL qui furent livrées à peu prêt au même moment ? Je parierais que n’importe quel client dirait qu’il ne se rappelle pas quelles versions étaient utilisées, ou comment elles se situaient face à la concurrence, et aussi qu’il s’en moque. Donc en prenant du recul, les différences dans les versions n’étaient pas un élément discriminant pour le client. Nous pouvons faire la même expérience en nous projetant dans l’avenir. QU’ARRIVERAIT-IL SI vous saviez que les prochaines versions LTS de Linux Ubuntu, Debian, Red Hat et Novell auraient les mêmes numéros de versions majeurs du noyau, de GCC, de X, de GNOME, de KDE, de OO.o et de Mozilla. Cela ferait-il une grosse différence pour vous ? Je parierais que non – du point de vue d’un client, les gens qui préfère X continueront de préférer X. Une personne qui préfère Red Hat restera sur Red Hat. Mais du point de vue d’un développeur, est-ce que cela faciliterait la collaboration ? Énormément.

Une autre personne dans l’assistance est montée pour parler de l’industrie de la mode. Cela convergea aussi vers un modèle très coordonné – les tissus et les technologies “arrivent” en premier, puis les concepteurs présentent leur travail simultanément lors de défilés autour de monde. Le “Printemps 2009″ voit les nouvelles collections de toutes les principales maisons, nombre d’entre-elles réutilisant des idées ou des composants similaires. Cela ne pose pas de problème à leur industrie, cela aide plutôt à prendre conscience du public potentiel.

Le dernier laboratoire, la nature, a aussi opté pour la coordination de la production. Anil Somayaji, qui était dans l’assistance lors de la présentation, a ensuite envoyé ceci par courrier électronique :

En gros, les arbres d’une espèce donnée synchroniseront la production de leur graines en temps et en volume, pour potentiellement combler leurs prédateurs et pour s’accorder avec les conditions environnementales. En effet, les productions synchronisées de graines sont une stratégie qu’utilisent les concurrents pour être sûrs qu’ils auront les meilleurs chances de succès. De façon similaire, si le logiciel libre pouvait “produire ses graines” de manière synchronisée (avec des types de logiciels ou des distributions ayant des plannings coordonnées, mais des logiciels dans différentes niches ayant des plannings différents), cela pourrait maximiser les chances de survie et de prospérité de tous.

Il n’y a pas de doute dans mon esprit que plus nous pourrons donner une “impulsion” forte, en coordonnant les périodes de gels et de publication des pièces majeures de la couche de logiciel libre, plus notre impact sur le marché global du logiciel sera fort, et mieux ce sera pour toutes les sociétés – de MySQL à Alfresco, de Zimbra à OBM, de Red Hat à Ubuntu.

Discussion sur la synchronicité du Logiciel Libre

Bernard Opic — Sun, 03 Aug 2008 22:43:18 +0200

Traduction française de l’article “Discussing free software synchronicity“.
Auteur : Mark Shuttleworth - Traducteur : Bernard Opic

—

Il y a eu une vague de discussions autour de l’idée de synchronicité dans les projets de logiciels libres. J’aimerais donner une vision plus globale, mais je suis à Prague en train de préparer le FOSSCamp et l’Ubuntu Developer Summit (je suis impatient de retrouver tout le monde !) ce qui fait que je ne livrerais que quelques réflexions et des réponses à des commentaires que j’ai vu.

Robert Knight a résumé les arguments que j’ai donné l’année dernière lors d’une présentation à l’aKademy. J’ai vraiment été ravi par l’annonce récente que les principales conférences annuelles des développeurs de GNOME et de KDE (GUADEC et aKademy) se dérouleront en 2009, au même moment et au même endroit. C’est un pas en avant important vers une collaboration encore meilleure. Des initiatives comme FreeDesktop.org ont été très utiles ces dernières années et la venue d’une conférence partagée accélérera la mise en avant des meilleures idées au sein des deux projets. Réunir tous les développeurs passionnés et dévoués de ces deux projets dans un même espace physique aura des retombés positives pour chacun des deux projets.

Aaron Seigo de KDE Plasma a opté pour une position résolument contre les cycles de versions synchronisés et ses trois articles récents sur le sujet sont intéressants à lire.

Aaron parle de problèmes à propos de fonctionnalités qui seront “bâclées” à la sortie d’une version pour rester dans le cycle. Il est tout a fait vrai que la discipline vis-à-vis de “ce qui est distribué” est essentielle pour permettre de s’engager sur des versions. Il est malheureux que des fonctionnalités ne soient pas toujours prêtes au moment où elles étaient prévues. Mais cela vaut la peine de réfléchir un peu à l’importance que représentent des fonctions spécifiques par rapport à une version complète. Lorsqu’une version arrive dans les temps, cela donne confiance dans le projet et cela déclenche une série de nouveaux tests, de la publicité, de l’enthousiasme et bien sûr des rapports de bogues. Le code neuf donne un coup de fouet et au final améliore. Les projets de logiciels libres ne sont pas comme les projets propriétaires – ils ne sont pas obligés de publier de nouvelles versions pour générer des revenus provenant de nouvelles licences et de mises à jours. Nous pouvons choisir de laisser passer une fonction particulière pour bénéficier d’une nouvelle phase de tests et de retours sur tout le code qui la compose.

Certains développeurs sont passionnés par des fonctions spécifiques, d’autres sont passionnés par le projet dans son ensemble. Il y a deux technologies spécifiques, ou plutôt méthodologies, qui ont énormément aidé à les séparer tout en leur donnant plus de force. Ce sont les systèmes de gestion de versions (Version Control System ou VCS) et le développement piloté par les tests (Test Driven Development ou TDD).

Nous avons découvert que les développeurs qui sont vraiment concentrés sur une fonction spécifique ont tendance à travailler sur cette fonction dans une branche (ou un ensemble de branches qui collaborent), en l’améliorant “jusqu’à ce que ça soit fini” sans ce préoccuper du cycle de version du projet. Ensuite ils fournissent la fonction dans son intégralité, généralement après avoir fait des tests. Ceci nécessite bien sûr de disposer d’un VCS qui sache très bien gérer la création de branches et la fusion. Vous devez pouvoir fusionner en permanence à partir du tronc principal, de sorte que la branche de votre fonction puisse toujours être fusionné *derrière* le tronc principal. Vous devez aussi pouvoir fusionner ce que font plusieurs développeurs qui travaillent tous sur les mêmes fonctionnalités. Bien entendu, Bazaar reste ma préférence réaffirmée en matière de VCS, car les développeurs ont pensé avec un très grand soin la façon de gérer la collaboration d’équipes sur différentes plates-formes, projets et flux de travail, mais n’importe quel VCS, même centralisé, peut convenir s’il gère bien les branches.

D’un autre côté, une suite de test complète vous permet d’être plus ouvert à de gros changements dans le tronc principal, car vous savez que les tests protègent la fonctionnalité dont disposaient les gens *avant* le lancement. Une suite de test est comme un champ de forces, protégeant l’intégrité du code dont on connaît le comportement, face à des changements constants. La plupart des projets que je finance ont adopté une approche de test avant lancement, dans lequel les lancements sont gérés par un robot qui refuse de valider le lancement tant que tous les tests n’ont pas été passés. Vous ne pouvez pas discuter avec un robot ! La beauté de tout ceci est que votre tronc principal est “toujours prêt à devenir une version”. En fait ce n’est pas *totalement* vrai, car vous voulez toujours faire un peu plus de contrôle qualité (QA) avant de laisser partir les bits, mais vous avez la merveilleuse assurance que la suite de test passera toujours. Toujours.

Donc, les VCS qui gèrent bien les branches et le développement piloté par les tests font toute la différence. Travaillez sur votre fonction jusqu’à ce qu’elle soit finie, puis intégrez la au tronc principal quand la phase est propice. Pour ceux qui tiennent compte de la version, la phase de gel de fonctionnalités est peut être plus étroite si vous avez de super tests.

Il y a beaucoup de discussions concernant la durée exacte d’un cycle “optimal”, avec des commentaires au sujet des phases de développement, de gel de fonctionnalités, de contrôle qualité et le reste. Je pense que c’est un peu noyer le poisson, quand vous utilisez un système qui gère bien les branches, car le développement de fonctionnalités ne s’arrête absolument pas lorsque le tronc principal est gelé en vue d’une version. Ceux qui préfèrent continuer à fixer leur branches le font, en se préoccupant de ce qui les intéresse le plus.

Pourtant, je continue de penser que les durées des cycles sont importantes. Aaron spécule sur le fait qu’un cycle de 4 mois pourrait convenir pour un site Web. Je suis d’accord, et dans le cas de Launchpad, après quelques variations sur le thème, nous sommes allé vers un cycle de 4 mois. La principale différence pour moi est que l’on a un seul point de déploiement du code en question, ce qui fait que l’on a pas à se préoccuper plus que ça de la compatibilité entre les mises à jour et les différentes versions. L’équipe de Launchpad à un système génial, d’où ils sortent chaque jour, du code frais provenant du tronc principal qu’ils envoient sur un ensemble de serveurs applicatifs (appelé “edge.launchpad.net”), que les bêta testeurs de LP utilisent par défaut. Une fois par mois, ils en sortent une nouvelle mouture qui est placée sur tous les serveurs d’application, de même lorsqu’ils révisent la base de données et peuvent introduire un nombre substantiel de nouvelles fonctionnalités. C’est serré, mais cela donne beaucoup de rythme au projet. Et nous planifions par “périodes de 4 mois”, au moins, le passage au cycle suivant. La dernière planification était de 9 mois, ce qui fut bien trop long.

Je pense que l’idée de cycles dans les cycles est super. Aaron explique que 6 mois est trop long pour des sorties fréquentes, et trop court pour pouvoir éviter de mettre à l’écart des fonctionnalités en les repoussant d’un cycle à l’autre. J’ai déjà dit que la volonté de rejeter une fonctionnalité qui n’est pas prête est une force plutôt qu’une faiblesse. Ce serait intéressant de voir si l’équipe de Plasma a adopté un cycle “interne” plus court, par exemple de 2 ou 3 mois, et si elle le fait tenir dans un cycle “externe” de 6 mois, en supposant que les problèmes d’Aaron aient été pris en compte.

Pour des projets importants, le fait que tout tourne autour d’une année s’avère être très important. Vous voulez vraiment un cycle qui se divise précisément en année, car beaucoup d’évènements externes se produisent sur cette base. Et vous voulez une certaine cohésion entre les parties. Chez Canonical, nous avions l’habitude de faire des points en suivant des cycles de 4 mois (3 fois par an) et d’avoir un cycle de 6 mois (deux fois par an) pour les versions d’Ubuntu, ce qui était excessivement complexe. Dès que nous nous sommes suffisamment connus les uns les autres, nous n’avons plus eu besoin de nous réunir tous les 4 mois, nous avons alors aligné les deux cycles et depuis tout est bien plus fluide.

Certaines personnes ont le sentiment que les distributions ne sont pas un facteur important dans le choix d’un cycle de version pour les projets en amont. Et d’une certaine manière c’est vrai. Il y aura toujours une “prochaine” version ou une autre distribution qui retiendra votre attention, et heureusement, une version d’un projet en amont qui rate “cette” version sera dans la suivante. Mais je pense que cela vous privera du bénéfice d’avoir mis au plus tôt votre travail à disposition d’un public plus large. Il existe une grande méthodologie de gestion de projet appelée “lean”, qui fonctionne comme cela. Et elle dit que lorsque vous travaillez sur un produit, le temps passé à attendre que quelqu’un d’autre ait fait quelque chose, est “gaspillé”. Vous pourriez avoir fait ce travail plus tard, et fait quelque chose d’autre avant qui aurait généré des résultats plus tôt. Tout ceci est basé sur les résultats étonnants provenant des vrais chaînes de production, telles que celles des voitures et de l’électronique.

Donc, bien qu’il soit certainement vrai que vous puissiez sortir une version qui rate la “vague”, mais qui attrape la seconde vague dans les six mois, vous êtes en situation de rater tous les rapports de bogues, les correctifs, et les autres opportunités d’enseignement et d’amélioration qui auraient pu arriver si vous aviez été sur la première vague. Il n’y a rien de moralement mauvais dans tout ça, et il y a probablement des choses plus importantes, mais néanmoins, cela vaut la peine d’y penser.
Certaines personnes ont dit que mon intérêt dans ce domaine était “pour Canonical”, ou “juste pour Ubuntu”. Et ce n’est pas vrai du tout. Je pense que c’est une approche plus productive pour tout l’écosystème du logiciel libre, et que cela nous aidera à rivaliser avec le monde propriétaire. C’est bon pour tout le monde. Et il n’y à pas qu’Ubuntu qui fasse des versions régulières tous les 6 mois, Fedora a adopté le même cycle, ce qui est formidable car cela augmente les opportunités de collaboration entre les deux distributions – nous avons plus de chances d’avoir les mêmes versions de composants clés à un moment donné.

Aaron dit :

Supposons que le projet A dépende de B, et que B sorte en même temps que A. Cela signifie que A va se retrouver un cycle derrière B en utilisant ce que B fourni, ou devra suivre vraiment de très près la fin du cycle de B pour pouvoir se servir de ce qu’il produit. Ce que vous souhaitez réellement est une approche décalée où B sort au moment ou A commence à travailler sur des choses.

Ceci va bien sûr complètement à l’encontre de la doctrine que prêche Mark, “tout le monde le même mois, tous les 6 mois”.

Je n’ai jamais suggéré que *tout le monde* devait sortir une version en même temps. En fait, pour Ubuntu nous avons convergé vers l’idée de faire une version environ un mois *après* celle de notre plus gros projet en amont prévisible, qui se trouve être GNOME. Et de manière similaire, le fait que le noyau ait un cycle relativement prévisible est très utile. Nous ne sortons bien sûr pas une version d’Ubuntu le même jour que la sortie du noyau, mais nous sommes capables de prévoir et de communiquer efficacement avec les gens de kernel.org concernant les versions autour desquelles nous avons de bonnes raisons de collaborer.

Plutôt que d’essayer et de sortir tout d’un seul coup, je trouve sensé de décaler les sorties en se calant grossièrement sur leurs dépendances.

Pour être bien clair, je ne demande pas aux projets que je vais mentionner ci-dessous de changer quoi que ce soit, je donne une image ou un scénario pour les besoins de la discussion. Chaque projet devrait trouver son propre rythme et se concentrer sur ce qui l’intéresse le plus. Je pense qu’il y d’importants bénéfices à tirer de la synchronicité, donc j’esquisse un scénario.

Imaginons que notre but soit d’avoir trois vagues de versions, espacées d’un mois.

Dans la première vague, nous avons le noyau, la chaîne d’outils, les langages et les bibliothèques système, et peut-être des composants critiques pour la performance – et la sécurité -. Linux, GCC, Python, Java, Apache, Tomcat, … sont des éléments qui nécessitent probablement le plus de stabilisation et de test avant d’être livrés à l’innocent, et ce sont aussi des éléments qui doivent être relativement statiques de sorte que d’autres éléments puissent aussi se stabiliser. Je pourrais aussi inclure là-dedans des choses comme Gtk.

Dans la seconde vague, nous avons des applications, les environnements de bureau et d’autres utilitaires. AbiWord et Koffice, Gnumeric et peut-être même Firefox (bien que certains pourraient dire que Firefox est un noyau et un gestionnaire de fenêtres … ;-)).

Et dans la troisième vague, nous avons les distributions – Ubuntu, Fedora, Gentoo, peut-être Debian et OpenSolaris. Le but serait d’encourager aussi plus de collaboration et de réflexion autour des versions de composants qui se trouvent dans les distributions, de sorte qu’elles puissent effectivement échanger des informations, des correctifs et des rapports de bogues.

J’ai vraiment un sentiment fort et persistant qu’il y aura plus d’intérêt pour les projets qui livreront leur code à un public plus large que pour ceux qui vérifieront leur VCS du jour, le tiendront à jour et le généreront. Et les distributions sont la meilleur façon de voir votre code … distribué ! Par conséquent, le fait que Fedora et Ubuntu aient convergé vers le même rythme est de très bon augure pour les projets en amont qui pourront ainsi bénéficier des tests plus nombreux, plus récurrents, très peu de temps après leur sortie. Je sais que chaque projet fera ce qui lui convient, et j’espère que cela leur conviendra aussi de pouvoir livrer leur code plus rapidement sur les serveurs et les ordinateurs de bureau de sorte que les correctifs puissent également arriver plus vite.

En prenant du recul sur la vision à six mois, il est clair qu’il y a un rythme de sortie plus lent des versions “entreprise”, “LTS” ou “majeures”. Ce sont celles que les gens prennent en charge pendant des années et des années. Ce sont aussi celles pour lesquelles les vendeurs de matériel veulent le plus souvent écrire des gestionnaires de périphériques. Et un gros problème pour eux est encore “quelle version de X, du noyau, de libC, de GCC, etc. devrons-nous prendre en charge ?” Si les distributions peuvent s’articuler, à la fois avec les projets en amont et le reste de l’écosystème, j’ai toutes les raisons de croire qu’avec une information claire les gens répondront que cela leur convient. J’ai parlé avec des développeurs du noyau qui ont dit qu’ils ADORERAIENT savoir quelle version du noyau va tourner dans RHEL ou une version LTS d’Ubuntu, parce que cela leur permettrait de prévoir leur travail en conséquence. Donc faisons-le !

Enfin, dans les commentaires sur les observations pertinentes de Russell Coker il y a une suggestion que j’aime beaucoup – c’est que les dates des phases de gel de fonctionnalités plus que les dates coordonnées pourraient faire la différence. Différentes distributions ont des points de vue différents sur la manière d’intégrer, de tester et de déployer du nouveau code, et fixer les dates de sortie suggère une réduction dans la flexibilité qu’elles pourraient avoir pour se positionner différemment. Je pense que c’est un point important. Je me suis initialement concentré sur la création d’un élan dans la communauté du logiciel libre, et encouragé davantage la collaboration. Si une version LTS d’Ubuntu, et une version de Debian, et une version de RHEL, utilisaient la même version majeure du noyau, de GCC et de X, nous pourrions améliorer grandement TOUTE la prise en charge des matériels actuels. Elles ne sortiraient pas à la même date, mais elles seraient toutes bien meilleures que si elles sortaient indépendamment. Et l’écosystème tout entier considérerait qu’un investissement dans du code ciblant ces versions clés se justifierait plus facilement.

Pourquoi wubi d'après Mark Shuttleworth

Cedynamix — Thu, 10 Apr 2008 07:37:00 +0200

Le président de Canonical, Mark Shuttleworth, a écrit sur son blog un raisonnement sur la motivation qui a fait naître Wubi et pourquoi il apparaît dans le LiveCD de Hardy.

Traduction de l'article original en français :

Windows est une plate-forme très importante et notre fierté justifiée en Linux et GNU ne doit pas nous faire oublier l'importance d'un logiciel qui est largement utilisé. Je crois que faire connaître les logiciels libres aux gens, est quelque chose de passionnant et l'un des principaux moyens pour y arriver est de leur montrer la puissance de ces logiciels libres tournant sur une plate-forme qui leur est familière, qu'il s'agisse de Windows ou de MacOS.

La réussite de Firefox, par exemple, est une source d'inspiration pour le logiciel libre et je suis certain que l'un des principaux moteurs de ce succès a été son excellente intégration dans l'environnement Windows. Un téléchargement rapide et une installation facile, après quoi les gens peuvent effectivement rester fidèle au logiciel libre, car il offre des innovations et une puissante expérience de navigation qui est, à l'évidence, meilleure que les solutions propriétaires. J'ai remarqué que les meilleurs projets de logiciel libre ont une belle histoire avec Windows. MySQL et PostGres en ont une. Bazar fonctionne bien aussi. Et les utilisateurs qui aiment, sont alors prêts à franchir une nouvelle étape vers le monde GNU.

Par conséquent, je suis absolument ravi de la manière dont Agostino Russo et Evan Dandrea ont dirigé le projet wubi, l'installateur Windows natif pour Ubuntu 8.04 LTS. Je crois qu'ils ont obtenu un résultat vraiment élégant pour traiter judicieusement avec le gestionnaire de démarrage de Windows afin d'offrir le choix Ubuntu. Si j'étais un utilisateur Windows intrigué par Linux, mais nerveux à son propos, ce serait une façon admirable d'obtenir un avant-goût de celui-ci, sans risque. Être capable d'installer et de désinstaller un système d'exploitation Linux comme s'il s'agissait d'une application Windows est une brillante innovation. Toutes mes félicitations à Agostino et Evan et aussi bien sûr à tous les pionniers qui ont eu cette façon de penser. Ils ont été clair, net et très professionnel:

Je suis un peu intimidé avec quelque chose d'aussi nouveau que wubi, étant la toute première expérience pour beaucoup de gens auront de Linux, du logiciel libre et de Ubuntu, mais les rapports initiaux sont positifs. J'ai eu une question de la part d'un médias qui a commencé avec un "ça n'a pas marché pour moi, mais... » qui fait que je suis un petit peu nerveux.

Bonne chasse.

Certaines incohérences et/ou approximations dans la traduction faites le savoir. Merci

Mark Shuttleworth blame l'ISO sur la victoire de OOXML

Cedynamix — Fri, 04 Apr 2008 12:26:00 +0200

Le fondateur de Ubuntu, Mark Shuttleworth, a dit que l'approbation du format OOXML de Microsoft comme standard est un "triste" jour pour l'ISO et le monde de l'informatique.

“Je pense que cette histoire détériore la confiance que les gens ont mise dans le processus d'élaboration des standards” a déclaré Shuttleworth dans une entrevue, quelques heures après que la nouvelle soit annoncée. Il estime que “L'International Standard Organization (ISO) n'a pas pris ses responsabilités”.

“Il est regrettable que l'ISO ne soit pas disposée à admettre que son processus de validation est un terrible échec”, a t-il dit, en indiquant par la même occasion que Microsoft a exercé de fortes pressions dans beaucoup de pays qui, traditionnellement, ne prennent pas part à l'ISO et a réuni des comités techniques avec des employés de Microsoft, des fournisseurs de solutions et revendeurs favorables à l'OOXML. “Quand vous avez un processus de validation basé sur la confiance et que l'on abuse de cette confiance, l'ISO doit stopper le processus”.

“L'ISO est un club d'anciens élèves ingénieurs réunis autour de sujets ennuyeux, alors il faut vraiment être passionné… et là, subitement, on se retrouve face à un énorme investissement d'argent et de lobbying, ce qui produit un résultat artificiel” a t-il dit en parlant du vote.“Le processus n'est pas armé pour combattre une pression corporative intense et c'est comme cela que vous vous retrouvez avec un standard qui n'est pas clair”.

"Plus de 3000 questions au sujet des spécifications restent sans réponse et l'OOXML est tellement complexe et ambiguë qu'il peut être mis en oeuvre de diverses façons, soutient Shuttleworth. Cela contredit la définition même d'un standard", ajoute t-il.

Office Open XML n'a pas sa place à côté des normes ISO, tels que HTML, PDF et ODF, affirme Shuttleworth.

“Les éléments qui conduisent à un très bon standard sont la clarté, le consensus ainsi que la véritable conviction que de multiples organisations pourront le mettre en oeuvre”, ajouté t-il, notant qu'une grande partie de l'OOXML est une compilation “de bizarreries et d'absurdités" des anciens Pack Office, déversés dans un format XML que les différents développeurs de Microsoft ont mis en oeuvre pour différentes versions de Word et Excel. “C'est un magnifique tas d'ordures qui a été normalisé” a affirmé Shuttleworth.

Tout comme Red Hat et Novell, la distribution Linux Ubuntu basée sur Debian utilise la suite bureautique open-source OpenOffice, compatible avec le Format OpenDocument, qui concurrence celui de Microsoft Office.

Ubuntu mettra-t-il en application la norme IS DIS 29500 maintenant que c'est standard ?

“Non, nous n'allons pas investir du temps à essayer de mettre en oeuvre un standard qui a été défini de manière déficiente” a répondu Mark Shuttleworth, en affirmant que les spécifications pourront être ajoutées et/ou changées au bon vouloir de Redmond et ce sans tenir compte des cycles de développement et de production de ses rivaux.

“Si nous nous approchions de la mise en application par exemple, Microsoft déplacerait la cage de but au dernier moment” souligne t-il. “Microsoft ne pense pas être lié par ce standard”.

“Je ne voudrais pas travailler à mettre en oeuvre ce standard même si les gens me le demandaient”, a t-il ajouté.

L'homologation par l'ISO donne à Microsoft la capacité de favoriser ses produits basé sur OOXML auprès des gouvernements et de ses clients, mais ne donne aucune garantie sur les changements dans le futur, de ces applications “Elle nous met dans une situation où nous avons de multiples standards pour plusieurs formats de documents et pas de directives claires quant à la manière dont vont évoluer ces normes”.

L'argument de Microsoft, de dire que le standard est complexe parce que le logiciel est complexe est une foutaise, affirme aussi Shuttleworth, parce que des logiciels plus complexes - comme ceux qui gèrent les emails et le web - ont des standards simples et clairs que tous les développeurs peuvent mettre en application : IMAP et HTML.

“Afficher une page web riche, très détaillé avec des polices, différentes présentations et le support de différents périphériques est complexe. C'est un format incroyablement riche en contenu, mais nous avons une norme pour le manier qui est propre et clair en comparaison avec Office Open XML”.

Pour terminer, c'est le même type pression et de politisation qui a condamné l'effort du Massachusetts dans l'etablissement du Format OpenDocument comme standard et a aussi torpillé l'effort global visant à s'unir derrière l'ODF, a revediqué Shuttleworth.

“Tout le travail a été effectué derrière des portes closes plutôt que de donner lieu à un débat public” a déploré Shuttleworth. “Tout ceci est très regrettable et ne fait pas réellement avancer la technologie et l'industrie. Nous avons toujours connu avec Microsoft des formats de fichiers propriétaires”.

Shuttleworth ne pense pas toutefois que cette victoire à l'ISO ralentira la marche en avant de Linux et soutient que la suite OpenOffice et les applications ODF continueront à monter en puissance. “Cela a toujours été une bataille difficile de faire utiliser autre chose que Microsoft Office“, dit-il. “La bataille sera gagnée au mérite”.

Traduction de l'article paru sur ZDNET.

Si vous trouvez certaines incohérences et/ou approximations dans la traduction faites le savoir