À partir de mars l’année prochaine, je concentrai mon énergie dans la conception de produits, les partenariats et la clientèle chez Canonical. Ce sont les choses qui me procurent le plus de plaisir et aussi celles qui me permettent le mieux travailler sur l’impact que nous avons sur l’Open Source et le marché technologique. J’ai cette possibilité car Jane Silber, qui a été la Directrice opérationnelle de Canonical pratiquement depuis le début, prendra le poste de Directrice.

Depuis que Jane à rejoint la société, elle et moi avons réparti la charge du travail de coordination entre les chefs de chacune des équipes clé de Canonical. Nous avons plusieurs fois échangé nos postes lorsque les nouvelles actions nécessitaient différents types de compétence ; à titre d’exemple, Jane encadre actuellement le projet Ubuntu One.

Je suis devenu vraiment passionné par la conception et la qualité, et je souhaite passer plus de temps pour comprendre comment nous pouvons tirer parti du processus collaboratif pour développer des produits, meilleurs et plus innovants. Je ne peux imaginer de défi plus intéressant, et je ne pouvais penser à meilleur personne que Jane pour reprendre mes responsabilités d’encadrement et de direction. Nous avons travaillé ensemble assez longtemps, et avec assez de proximité, pour que je puisse être confiant sur la suite qui sera donnée aux points qui me tiennent le plus à cœur et impatient de voir où Jane va placer la barre pour l’équipe des seniors. En tant qu’ancienne vice-présidente chez General Dynamics, Jane a plus l’expérience des gros clients et de la direction de grandes organisations, ce qui me paraît essentiel pour Canonical dans les cinq années à venir. Nous sommes bien accueillis comme partenaire et fournisseur de sociétés de plus en plus importantes, et je veux être sûr que nous sommes une réponse fiable à leurs besoins.

Beaucoup de personnes dans la communauté connaissent Jane par les conférences de développeurs Ubuntu et elle est bien établie en tant que dirigeant chez Canonical. Pour pouvoir se concentrer sur nos nouveaux postes, nous recruterons un Directeur opérationnel et un nouveau meneur pour Ubuntu One (ces deux postes à pourvoir seront annoncés publiquement ainsi que dans Canonical). Il n’y a pas d’urgence, nous avons prévu de coordonner les choses avec soin et j’espère que je serais à pied d’œuvre dans mon nouveau poste en mars.

Source : My new focus at Canonical

Des cycles de six mois sont parfaits. Parlons maintenant des méta-cycles : des cycles de version plus longs pour des travaux majeurs. Je suis très intéressé par un échange entre communautés sur ce sujet, je vais donc esquisser quelques idées et encourager les personnes d’autant de communautés du Logiciel Libre que possible a déposer leur commentaires ici. Je résumerais ces commentaires dans un billet ultérieur, qui sera sans nul doute bien plus réfléchi et pertinent que celui-ci :-)

Avant-propos : baser la cadence sur les bonnes pratiques

La pratique des versions régulières, et maintenant des versions à intervalles de temps réguliers, devient courante dans la communauté du Logiciel Libre. Du noyau, à GNOME et KDE, à X, et à des distributions comme Ubuntu, et Fedora, l’idée d’un cycle régulier et prévisible est maintenant mieux compris et plus largement adopté. Plusieurs personnes plus intelligentes que moi ont présenté les bénéfices d’une telle cadence : dynamiser la communauté toute entière, publier VRAIMENT plus tôt et plus souvent, mélanger le bon et le mauvais code, phase de correction rapide.

Il y a eu quelques expériences avec différents cycles. Je suis impliqué dans des projets qui ont des cycles de 1 mois, 3 mois et 6 mois, pour différentes raisons. Ils fonctionnent tous bien.

… mais concernant les besoins du long terme

Mais il y a aussi des défauts dans le cycle de six mois :

• il est difficile d’expliquer à vos utilisateurs que vous avez fait des modifications définitives et significatives ;
• il est difficile de savoir pour combien de temps il faut assurer du support, vous ne pouvez évidemment pas supporter chaque version indéfiniment.

Je pense qu’il y a un consensus grandissant sur ce point, des deux côtés du débat sur la « cadence » originelle?

L’histoire de deux philosophies, avec peut-être une théorie unificatrice

Il y a quelques années, à l’AKademy de Glasgow, j’étais au centre d’un grand débat sur les cycles de six mois. J’étais un fervent défenseur du cycle de six mois, et j’étais intéressé par les arguments contradictoires. Le plus fort de ces arguments concernait la faisabilité de « changements importants ».

Le refrain habituel était que « Il y a des choses que l’on ne peut tout simplement pas faire en six mois ». « On doit pouvoir prendre plus de distance, et il faut planifier les grands changements ». GNOME a beaucoup été critiqué pour avoir « stagné » à cause de son incapacité à faire des choix judicieux dans un cycle de six mois (et avec les perpétuelles garanties de rétro-compatibilité). De telles discussions deviennent souvent idéologiques, avec d’un côté certaines personnes qui disent que « On peut tout faire évoluer de façon incrémentale » et d’autres qui disent que « Il faut faire une rupture nette ».

À l’époque, KDE se préparait pour KDE 4.0, une initiative importante et courageuse s’il en est. Et GNOME semblait heureux de produire ses versions régulières. Lorsque la version de KDE est arrivée, elle était belle, mais elle avait a de vrais problèmes. Comme on pouvait s’y attendre, les partisans des versions régulières déclarèrent « regardez, nous vous l’avions dit, les GROSSES versions ne marchent pas ». Mais depuis, KDE a cessé de faire des améliorations régulières, bien cadrées et incrémentales, et KDE est superbe. Les avantages de ce geste audacieux apparaissent maintenant clairement. Bien joué KDE :-)

De son côté, GNOME est maintenant plus conscient des limites des versions régulières. Je suis très excité par l’enthousiasme et l’esprit avec lequel la campagne « l’expérience utilisateur COMPTE » est reprise dans Gnome, il y a une réelle volonté d’offrir des changements révolutionnaires. Cela a commencé l’an dernier lors de la réunion au sommet de Gnome sur l’ergonomie, que j’ai apprécié et à laquelle ont participé quelques membres des équipes de Canonical en charge de l’ergonomie et du design, et les fruits de cette évolution des tendances se profilent dans des choses comme le nouvel environnement Activités.

Il est maintenant clair qu’un changement comme celui-ci représente une rupture définitive avec le passé et qu’il prendra plus qu’une version conçue en six mois pour arriver à maturité. Et plus important que tout, il s’agit d’une occasion de faire d’autres modifications significatives et rompant avec le passé. Une rupture avec le passé. Un geste audacieux. Et il y a donc eu une série de conversations sur la façon de « faire une 3.0 », en clair, comment rompre avec la tradition du changement progressif, afin de rendre cette vision possible.

Il me semble que les deux projets convergent vers un ensemble commun d’idées :

• Les versions rapides et prévisibles sont parfaites pour maintenir la motivation et faire évoluer le code de manière propre et efficace, elles évitent d’aller à l’échec, elles consolident les choses et permettent de laisser murir les bonnes et les mauvaises idées de manière coordonnée et gérée.
• Les grandes versions sont énergisantes. Elles sont motivantes, elles donnent aux gens le sentiment qu’il est possible de changer quelque chose, elles libèrent beaucoup d’énergie créative et génèrent de nombreuses et saines discussions. Mais elles peuvent être un peu brouillon, des choses peuvent se casser en route, et c’est une bonne chose.

De façon anecdotique, il y a d’autres histoires intéressantes qui se nourrissent de tout cela.

La communauté Python a récemment décidé que Python 3.0 aurait un cycle plus court que les versions habituelles de Python. La version 3.0 sert à secouer les idées et le code pour les versions 3.x, mais elles ne sera pas adoptée massivement ce qui fait que cela n’a pas vraiment de sens de faire beaucoup d’effort pour la maintenir – on la sort, avec un cycle court, et on investit ensuite dans la qualité durant le cycle suivant parce que la version 3.x sera beaucoup plus utilisée que la 3.0. Cela me rappelle beaucoup KDE 4.0.

Je suis donc intéressé par les opinions, les défis, les idées, les engagements, les hypothèses, etc. à propos de l’idée des méta-cycles et comment nous pourrions nous organiser pour en tirer avantage le plus possible. Je crois que nous pouvons définir une bonne pratique, qui inclut des versions régulières pour une amélioration continue suivant un calendrier prévisible, et AUSSI définir une bonne pratique pour savoir comment les version MAJEURES se situent dans cette cadence, de manière très structurée et gérable. Je pense que nous pouvons tirer profit des expériences de GNOME et KDE, et d’autres projets, pour construire cette réflexion.

C’est également important pour les distributions

Les principales distributions ont tendance à avoir des versions importantes, aussi bien que des versions fréquentes. RHEL a Fedora, Ubuntu fait des versions LTS, Debian suit le rythme de sa logique d’intégration continue à l’extrême avec Sid et Testing :-) .

Lorsque nous avons fait Ubuntu 6.06 LTS nous disions que nous en ferions une autre dans « 2 ou 3 ans ». Quand nous avons fait la 8.04 LTS nous disions que les bénéfices de la prédictibilité d’une LTS sont tels qu’il serait bien de dire à l’avance quand serait la prochaine LTS. Je disais que j’aimerais que ça soit la 10.04 LTS, un cycle majeur de 2 ans, à moins que nous ayons la possibilité de coordonner les versions majeures avec une ou deux autres des principales distributions – Debian, Suse ou Red Hat.

J’ai parlé avec des gens de chez Novell, et il ne semble pas qu’il y ait de possibilité de se synchroniser pour l’instant. En discutant avec Steve McIntyre, le leader du projet Debian, nous avons repéré une possibilité de collaboration intéressante. Debian vise un cycle de 18 mois, qui amènerait leur prochaine version en octobre 2010, ce qui correspondrait avec la sortie de la version Ubuntu 10.10. Nous pourrions donc retarder la LTS d’Ubuntu jusqu’en octobre 2010, en nous synchronisant et en collaborant avec le projet Debian pour avoir des versions très proches en termes de choix d’infrastructure. Cela faciliterait grandement le partage des correctifs, un plus pour tout le monde. Puisqu’il y aura beaucoup de gens d’Ubuntu à la Debconf, et espérons un grand nombre de développeurs Debian à l’UDS de Barcelone en mai, nous aurons des chances d’examiner cette possibilité en détail. Si cette idée reçoit un accueil favorable, plait et suscite beaucoup d’implication chez Debian, je serais prêt à promouvoir l’idée de faire passer la LTS de 10.04 en 10.10 LTS.

Questions et options

Alors, quelles pourraient être les « bonnes pratiques » d’un méta-cycle ? Quelles sortes de choses devraient être prises en compte dans la planification de ces méta-cycles ? Quels problèmes entraîneraient-t-elles, et comment ceux-ci seraient-ils le mieux traités ? Comment les cycles courts (3 mois, 6 mois) se situent-ils dans un méta-cycle plus large ? Poser ces questions à de nombreuses communautés aidera à tester les idées et à retenir les meilleures d’entre-elles.

Quel nom conviendrait bien à ce type de méta-cycle ? Méta-cycle fait … très méta.

Il est vrai que la “première version d’un cycle majeur” (KDE 4.0, Python 3.0) est mieux faite dans la mesure où un cycle court n’empiète pas sur l’attention à porter au long terme ? Y a-t-il des contre-exemples, ou de meilleurs exemples, de ceci ?

Quelle version dans un cycle majeur est-elle la plus indiquée pour le support à long terme ? Est-ce la dernière des versions avant que de nouveaux changements important surviennent (Python 2.6 ? GNOME 2.28 ?) ou est-ce le résultat de quelques itérations rapides sur la versions X.0 (KDE 4.2 ? GNOME 3.2 ?) Est-ce important ? Je crois qu’il y a avantage pour les projets en amont à supporter occasionnellement une version pendant une période plus longue que d’habitude, parce que c’est ce que les grandes sociétés souhaitent.

Est-ce qu’un cycle d’une année complète serait bénéfique ? Est-ce que par exemple 2 ans et demi serait une bonne idée ? Personnellement, je ne pense pas. Je pense que les conférences et les vacances ont tendance à se passer au même moment chaque année et c’est bien plus facile de raisonner en termes de cycles d’années complètes. Mais au cours de discussions informelles à ce propos, certains ont dit que 18 mois, d’autres que 30 mois (2 ans et demi), pourrait leur convenir. Je pense qu’ils sont diiiingues, qu’en pensez-vous ?

Si ce n’est pas 2 ou 3 ans, qu’est-ce qui vous conviendrait le mieux ? Du côté matériel les gens ont tendance à dire « 2 ans ! » pour bénéficier plus tôt des nouveaux matériels. Pour ce qui est du logiciel ils disent « 3 ans ! » pour avoir  moins de changements à gérer. Personnellement, je suis dans le camp des 2 ans, mais je pense qu’il est plus important de s’aligner sur le rythme de la communauté, et si GNOME, KDE ou le noyau voulaient 3 ans, je serais partant.

Comment les méta-cycles de différents projets cohabitent ? Cela a-t-il un sens d’avoir des choses de bas-niveau relatives au matériel sur un cycle différent que d’autres de haut-niveau visibles par l’utilisateur ? Ou bien cela a-t-il plus de sens d’avoir un rythme de vie commun de haut en bas ?

Cela aurait-il plus de sens d’étaler les versions à long terme en fonction de leur dépendance à une autre, comme GCC puis X et OpenOffice ? Ou bien cela aurait-il plus de sens de leur faire suivre à toutes le même méta-cycle, afin que nous ayons par moment des changements radicaux, et à d’autres beaucoup de stabilité ?

Y a-t-il des projets qui fonctionnent déjà comme cela ?

Y a-t-il des théories ou des pratiques établies dans ce domaine ?

Une discussion entre communautés

Si vous avez lu jusqu’ici, merci ! Veuillez commenter, et si vous êtes intéressé alors veuillez remonter ces questions dans les communautés dont vous vous occupez, et rapportez les résultats de ces discussions ici sous forme de commentaires. Je suis quasiment sûr que nous pouvons faire évoluer l’art du logiciel à un niveau supérieur si nous pouvons tirer parti du fait que nous ne sommes PAS propriétaires, et c’est une des clés pour y parvenir.

Source : Meta-cycles: 2-3 year major cycles for free software?

Grâce aux efforts concertés de Martin Pitt, Sébastien Bacher et plusieurs autres, notify-osd et d’autres composants liés sont arrivés dans Jaunty la semaine dernière. Merci beaucoup à tous ceux qui ont participé ! Et merci à David Barth, Mirco Muller et Ted Gould qui ont encadré le développement de notify-osd et de l’indicateur de messagerie associé.

Notify-OSD prend en charge les notifications des applications et de touches spéciales du clavier comme la luminosité et le volume.

MPT a publié une présentation du framework conceptuel pour la “gestion de l’attention” sur https://wiki.ubuntu.com/NotificationDesignGuidelines, qui place la notification éphémère dans le même contexte que les différents outils que les applications peuvent utiliser lorsqu’elle n’ont pas le focus mais doivent indiquer quelque chose à l’utilisateur. C’est une ébauche, et lorsqu’elle sera en 1.0 nous la déplacerons sur un nouveau site qui hébergera les modèles de conception sur Canonical.com.

Il y a aussi une spécification détaillée de notre implémentation de l’agent d’affichage de notifications, notify-osd, qui est visible sur https://wiki.ubuntu.com/NotifyOSD et qui décrit non seulement le comportement de notify-osd mais aussi toutes les mises à jours relatives que nous devons apporter aux paquets de main et universe pour faire que ces applications utilisent la notification et les autres techniques de façon consistante.

Il y a au moins 35 applications qui ont besoin de modifications, et peut-être même d’autres ! Si vous trouvez une application que n’utilise pas les notifications élégamment, veuillez l’ajouter à la page des lignes directrices pour la conception de notifications, et si vous soumettez une bogue sur le paquet, veuillez l’étiqueter “notifications” afin que nous tracions ces problèmes de manière unique et homogène.

Avec notify-osd, nous avons téléversé un nouvel indicateur pour le tableau de bord qui est utilisé pour fournir un moyen de répondre aux évènements de messagerie, tels que le courriel et les pings IRC. Si quelqu’un vous contacte par messagerie instantanée, vous verrez une notification éphémère, et l’indicateur de messagerie vous permettra de répondre immédiatement. Même chose pour le courriel. Pidgin et Evolution sont les premiers à bénéficier de ce travail, avec le temps nous l’étendrons aux autres applications de messagerie instantanée et de courriel de l’archive – les correctifs sont les bienvenus :-)

Il y aura des correctifs grossiers. Les applications qui ne se conforment pas à la spécification de FreeDesktop.org et qui implémentent des actions sur des notifications même lorsque l’agent d’affichage indique qu’il ne les prend pas en charge, verront leurs notifications transformées en alertes. C’est le principal objet de notre effort actuel, l’identification et la correction de ces applications. Nous savons aussi qu’il y a plusieurs cas où un framework de réponse persistante est nécessaire. L’indicateur de messagerie en gère une grande partie, en octobre nous mettrons en place d’autres outils dans Karmic pour prendre en charge la persistance.

Source : New notification work lands in Jaunty

Comme cela a été largement commenté, la Russie a fermé l’accès public aux vols spatiaux commerciaux à bord de Soyuz prévus après la mise en retraite de la navette spatiale américaine.

Maintenant que l’ISS peut recevoir une équipe permanente plus importante, les places seront plutôt réservées aux rotations de longue durée des équipes de l’ISS qu’aux petites visites sur l’ISS, qu’il s’agisse de visites concernent des astronautes professionnels européens ou américains ou bien des personnes effectuant un vol privé. Je crois que les raisons économiques liées aux places Russes soient les mêmes dans les deux cas – les européens et les américains doivent payer pour le vol comme nous autres passagers ordinaires.

Il y a plusieurs points intéressants dans cette histoire.

Le premier est que, lorsque la navette sera à la retraite, les Russes disposeront du seul moyen d’accès au vol orbital habité au sein du partenariat ISS. La Russie et la Chine seront les seules nations pouvant effectuer des vols orbitaux habités, et les États-Unis refusent avec dédain d’accueillir la Chine dans le club ISS. Il faut s’attendre à ce que le prix d’une place augmente substantiellement tant que ce sera le cas.

Un autre est le projet européen de transformer leur vaisseau cargo autonome (ATV) en appareil habité, c’est à mon avis une chose tout à fait réalisable et sensée.

Et un troisième point est que les russes sont depuis longtemps ouverts aux offres commerciales pour des vols de longue durée (rotation de six mois d’équipe ISS). Cela nécessiterait davantage d’entraînement (12 à 18 mois selon à qui vous posez la question) mais impliquerait certainement que le vol Soyuz fasse l’aller-retour.

Source : Commercial access to space on hold

Parlons des notications ! Comme l’a mentionné Ryan Lortie, il a eu beaucoup de discussions entre les communautés Ubuntu, Kubuntu, GNOME, KDE et Mozilla qui étaient représentées à l’UDS au sujet des propositions faites pour Ubuntu 9.04 par les équipes de Canonical en charge de la conception de l’interface utilisateur de l’ingénierie du poste de travail.

Voir la vidéo de présentation au format Flash.

Il y a quelques idées assez audacieuses (lire : controversées) que nous avions envie d’explorer, c’était fantastique d’avoir la possibilité d’en discuter avec un large échantillon de la communauté. Il y avait plusieurs points délicats et des pièges qu’à mon avis nous avons réussi à éviter dans un premier temps, grâce à tous ceux qui ont participé. Certaines des choses sur lesquelles nous travaillons dans ces équipes sont faites en direct avec des partenaires pour leurs appareils, ce qui fait qu’ils ne voient pas ce niveau de discussion avant de livrer, mais c’est formidable quand nous avons l’opportunité de le faire.

Certaines de ces idées ne sont pas prouvées, elles se résument à des questions de point de vue, mais puisque notre engagement à leur égard se fonde sur le désir d’en savoir plus je les vois comme des expériences constructives. Les expériences ne sont que ça – des expériences. Elles peuvent être des succès ou des échecs. Nous devrions les juger avec précaution, une fois que nous avons les informations en main. Nous apportons de nouvelles idées pour le poste de travail Libre, sans égo. Nous savons que ces idées pourraient être meilleures ou pires que des travaux similaires faits dans d’autres communautés, et nous voulons recueillir les impressions de vrais utilisateurs pour tenter de trouver le meilleur compromis pour tout le monde. Les meilleures idées, et le meilleur code, formeront au final une partie des communs numériques du Logiciel Libre et seront partagés par GNOME, KDE et chaque distribution. Donc, à ceux qui sont ennuyés par le fait que nous puissions livrer autre chose que GNOME ou KDE par défaut, je voudrais leur demander d’être patient et de nous soutenir – nous voulons contribuer par de nouvelles idées et du code neuf, et cela implique quelques différences qui pourront servir de base à des discussions au sujet des orientations futures des projets en amont. Par le passé, nous avions peu de différences de ce type dans Ubuntu. Certaines, comme la disposition actuelle du poste de travail, ont été largement adoptées. D’autres, comme l’infâme “mode spatial Ubuntu”, ne l’ont pas été. C’est la vie, et nous bénéficions tous de l’évolution.

Les expériences sont aussi des choses que nous ne devrons pas faire à la légère. Le poste de travail sous Ubuntu est une chose qui me tient à cœur ; je me sens personnellement responsable de la productivité et de la satisfaction de chaque utilisateur de Ubuntu, donc lorsque nous proposons de nouvelles idées et du code pour le poste de travail je pense que nous devons faire tout ce que nous pouvons pour être sûr de réussir du premier coup. Nous ne devons pas infliger de mauvaises idées à nos utilisateurs juste parce que nous sommes curieux, arrogants, butés ou fiers. En dépit du fait que nous puissions occasionnellement être curieux, arrogants, butés et fiers :-)

Alors, que proposons-nous ?

Tout d’abord, nous portons de l’attention aux notifications sur le poste de travail dans le cadre d’une étude plus large sur “l’espace entre les applications”.

Je pense que la meilleure aide que Canonical et Ubuntu puissent apporter à la cause du Logiciel Libre sera de s’investir sur les points de frictions qui existent entre les principaux composants du poste de travail. En d’autres termes, bien qu’il y ait déjà de grandes communautés en amont sur des applications individuelles pour le poste de travail du Logiciel Libre (Novell pour Evolution, Sun pour OpenOffice, Mozilla pour Firefox, Red Hat pourNetworkManager), nous pensons qu’il a beaucoup de travail productif et utile à faire sur ce qu’il manque entre elles. Les notifications sont des choses que font de nombreuses applications, et si nous apportons de nouvelles idées dans ce domaine alors nous aiderons à améliorer l’interface utilisateur de toutes ces applications. C’est un beau démultiplicateur de force – nous espérons faire un travail qui rende celui des autres communautés encore plus précieux.

Quoi qu’il en soit, attendez-vous à des heurts. Les idées que nous explorons peuvent entrer, pourront entrer et entrent déjà en conflit avec des concepts présents dans différentes applications. Nous pouvons nous occuper du code correspondant dans les paquets de « main », mais je suis plus préoccupé par la gestion d’une perturbation sociale potentielle que le conflit pourrait créer, et c’est plus une question de dialogue que de programmation.

Les notifications sont intéressantes, subtiles et complexes. Il y a beaucoup d’approches différentes sur de nombreuses plateformes différentes. Il y a beaucoup de scénarios d’utilisation. Nous essayons de réduire et d’éliminer la complexité, tout en permettant de traiter les scénarios d’utilisation que nous connaissons.

Il y a eu du bon travail de fait sur les notifications dans la communauté freedesktop.org, et même une spécification qui est *presque* en 1.0 dans cette communauté, avec des implémentations Open Source. Nos suggestions sont basées sur cette spécification, mais elles déprécient certaines de ses fonctions. Nous serons probablement compatibles avec l’interface de programmation applicative actuelle pour l’envoi des notifications, mais nous n’afficherons probablement pas toutes les notifications qui pourront être envoyées, si elles requièrent l’emploi de fonctions que nous déprécions. Si cette expérience se passe bien, nous espérons aider cette spécification de FD.o à passer en 1.0, avec ou sans nos modifications.

Les principales suggestions que nous faisons sont les suivantes :

• Il ne devrait y avoir aucune action sur les notifications.
• Les notifications ne devraient pas être affichées de manière synchrone, mais devraient pouvoir être placées en file d’attente. Notre implémentation de l’agent d’affichage des notifications n’affichera qu’une notification à un moment donné, d’autres pourrons procéder différemment.

C’est à peu près tout. Il y a des subtilités et des variations, mais ce sont les suggestions fondamentales que nous faisons, et que nous explorerons dans un netbook avec un partenaire, de même que dans la version générique de Ubuntu 9.04, à la grâce de Dieu.

Ce travail débouchera sur un nouvel agent d’affichage des notifications, et non sur une branche ou une modification de l’agent de notification actuel de GNOME. Nous ne pensons pas que l’interface de programmation applicative cliente – libnotify – ait besoin d’être modifiée pour cette expérience, bien que nous puissions ne pas afficher des notifications envoyées via cette interface de programmation applicative qui utilise des fonctions que nous suggérons de déprécier. Nous essaierons de faire en sorte que les paquets dans « main » soient modifiés de manière appropriée, et nous espérons que le MOTU aidera à l’identification et à la mise à jour des paquets requis dans « universe ».

Pourquoi un nouvel agent d’affichage des notifications ? Nous le concevons pour être développé avec Qt sur KDE et Gtk sur GNOME. L’idée est d’avoir le plus de code possible en commun, mais de pouvoir néanmoins tirer parti de l’environnement d’affichage de texte approprié sur Ubuntu et Kunbuntu. Nous espérons livrer les deux simultanément, et nous en avons parlé avec des membres des deux communautés Ubuntu et Kubuntu. Pour l’instant, il y a quelques désaccords entre GNOME et KDE à propos du statut de la spécification de FD.o, et nous espérons que nos efforts aiderons à établir un pont entre les deux communautés. Dans Ubuntu 9.04, nous souhaitons continuer à maintenir et à publier les paquets de l’agent de notification existant en complément, pour offrir les deux options aux utilisateurs qui ont une préférence particulière. En général, là où nous investissons dans des travaux expérimentaux, nous prévoyons de continuer à offrir un composant ou un paquet standard de GNOME ou de KDE dans l’archive de sorte que chacun puisse en profiter à sa guise.

Le point le plus controversé de cette proposition est l’idée que les notifications ne doivent pas être associées à des actions. Autrement dit, pas de boutons, d’ascenseurs, de liens ou même d’annulation [x]. Lorsqu’une notification arrivera, vous ne pourrez pas cliquer dessus, vous ne pourrez pas la faire disparaître, vous ne pourrez pas continuer vers une autre fenêtre ou une page Web. Vous aimez cette liberté ? Hmmm ? Aliénation, à première vue, mais il y a de la méthode dans cette aliénation.

Notre hypothèse est que l’existence de N’IMPORTE QUELLE action crée une obligation pressante d’agir, ou de PENSER À AGIR. Cela fait passer les notifications du statut de jeu à celui de travail. Cela leur donne de lourdes responsabilités. Cela en fait des interruptions, non des notifications. Et les interruptions sont ennuyeuses lorsque vous avez des choses à faire.

Nous avons donc à nous battre sur trois fronts.

1. Nous voulons rendre les notifications vraiment éphémères. Elles sont ici, et puis elles sont parties, et c’est la vie. Si vous êtes devant votre poste de travail lorsqu’une notification arrive, vous la percevrez, et si vous voulez vous pourrez la REGARDER, et elle sera belle, claire et simple à comprendre. Si vous voulez l’ignorer, vous pourrez le faire sans crainte et elle partira chaque fois sans que n’ayez à l’annuler, c’est OK. Les notifications concernent uniquement des choses que vous pouvez ignorer ou manquer. Si vous êtes sorti prendre un café et qu’une notification arrive, vous ne vous en porterez pas plus mal. Elles ne s’empilent pas comme le courriel, il n’y a pas de journal de celles que vous avez raté, vous ne pouvez pas faire défiler l’écran en arrière et les voir à nouveau, et d’ailleurs vous n’avez pas d’obligation de le faire – elles ne peuvent pas devenir un travail alors que vous êtes déjà occupé à quelque chose d’autre. Elles sont parties comme une fille mystérieuse dans le bus que vous n’avez pas pris, et elles enrichissent votre vie exactement de la même manière !
2. Nous pensons qu’il devrait y avoir des indicateurs persistants pour les choses que vous devez réellement savoir, même si vous avez raté la notification parce que vous avez eu un besoin urgent d’un café. Nous sommes donc en train de faire une liste de ces choses, et nous prévoyons de les implémenter.
3. Tout le reste devrait être traité via une fenêtre qui attire l’attention, située en arrière-plan, à moins que ce soit vraiment important auquel cas la fenêtre pourrait passer en avant-plan.

Comme il s’agit clairement d’un travail sur plusieurs versions, nous pourrons identifier des problèmes et des inconsistances en chemin notamment à l’occasion des points de contrôles. J’espère que non, mais ce n’est pas improbable, en particulier lors de la première itération. Ces idées pourraient également se révéler sans intérêt, et nous devrions être prêts à changer de direction en fonction des retours une fois que nous aurons une implémentation dans la nature.

Nous avons eu un superbe « sprint » UXD et DEE (équipe conception de l’interface utilisateur et équipe ingénierie du poste de travail) à San Francisco la semaine précédent l’UDS. Merci à tous ceux qui y ont participé, en particulier ceux qui venaient d’autres équipes. Ce travail sur les notifications pourrait bien n’être que la partie visible de l’iceberg, mais c’est un joli petit morceau :-)

Un ou plusieurs de nos partenaires OEM proches (sociétés avec lesquelles nous travaillons sur les nouvelles fonctions du poste de travail) proposeront probablement ces fonctionnalités via un netbook au cours du cycle 9.04. À ce stade, nous déposerons également le code dans un PPA pour effectuer des tests avec un plus grand nombre d’applications. Il y a des discussions actives concernant la révision de la spécification de freedesktop.org en se basant sur ce travail. Je pense que nous devrons être prudents, et que nous devrons collecter les impressions de vrais testeurs ainsi que des données solides, mais si tout ce passe bien nous pourrons proposer une simplification de la spécification, et nous soumettrons notre agent d’affichage de notifications à FreeDesktop.org. Une collaboration à long terme autour du code aura lieu sur Launchpad.

Source : Notifications, indicators and alerts

L’équipe interface utilisateur et design de Canonical compte quelques personnes dédiées à la technologie Web. À l’heure actuelle, un effort important est fait pour remodeler l’interface utilisateur de Launchpad maintenant que le noyau des fonctionnalités pour le suivi des bogues entre projets, la publication de code et la traduction est en place. Nous voulons clarifier la réalisation de tâches – en particulier pour les nouveaux utilisateurs – et nous voulons que lorsque vous apportez de petites modifications à votre projet, cela soit intuitif et réactif.

Au cours des discussions sur le design, nous avons passé beaucoup de temps à travailler sur une nouvelle approche des “boîtes de dialogues, assistants et flux de travaux”, en essayant de solutionner un problème épineux dans l’interaction avec l’utilisateur : comment simplifier quelque chose qui est complexe à réaliser ? Il y a de nombreuses situations dans Launchpad où vous devez être très bien organisé avant de pouvoir faire quelque chose. Par exemple, vous pourriez avoir besoin de vous assurer qu’il y a une équipe incluant des personnes spécifiques avant d’abonner cette équipe à une bogue. Vous pourriez aussi avoir besoin de créer une nouvelle version pendant que vous faites du triage et de la planification de travail à faire sur des bogues dans votre projet.

Actuellement, cela implique que vous alliez dans différents endroits de Launchpad avec une aisance qui suppose que vous savez exactement comment toutes les parties fonctionnent. Vous devez aller dans un endroit pour enregistrer une équipe et dans un endroit complètement différent pour créer une version. Cela fait que de nombreuses personnes n’utilisent pas certaines fonctionnalités de Launchpad, car elles doivent comprendre le système dans son ensemble avant de pouvoir faire la moindre chose. Chaque fois que quelqu’un se casse la tête là-dessus, nous échouons ! Et c’est le problème que nous avons cherché à résoudre.

Nous sommes arrivés à une solution astucieuse, que nous avons appelé formulaires dynamiques (« morphing dialogs »), qui assure que l’utilisateur a toujours un nombre minimum de choix à faire, et qui autorise néanmoins des variations complexes au cours d’un processus tout en restant assez naturelle aux utilisateurs.

Les idées clés sur lesquelles reposent les formulaires dynamiques sont :

• Ne requérir qu’une seule décision importante à la fois, et faire en sorte qu’elle soit explicite. Il y a parfois plusieurs façons de faire quelque chose, mais il y a en général un seul chemin normal que les utilisateurs peuvent suivre, et nous voulons toujours que les utilisateurs puissent faire facilement les choses simples.
• Donner aux utilisateurs une idée de l’avancement du processus, sans être trop dogmatique, car la réalisation d’une étape implique souvent qu’il faille faire d’autres choses en parallèle et que ces détours peuvent également nécessiter plusieurs étapes.

Voici une vidéo d’exemple, qui montre une personne liant un schéma directeur à une bogue. Il doit chercher le schéma directeur adapté, ce qu’il peut faire sur plusieurs projets simultanément. Dans le cas présent, il ajoute GNOME à la liste des projets dans lesquels il recherche un schéma directeur, et lorsqu’il ne peut pas le trouver, il va enregistrer un nouveau schéma directeur correspondant à ce qu’il veut. À la fin, il décide de revenir en arrière et d’en choisir un dans les résultats d’une recherche. Rien de tout cela n’a induit le chargement d’une page, et les allers-retours avec le serveur sont moins coûteux que le chargement de pages complètes, puisque nous pouvons obtenir ce dont nous avons besoin de manière très optimisée.

Vous pouvez voir quelques idées clés se dégager de la vidéo.

Notez que la “barre de progression” – la ligne verte – n’est pas particulièrement grande ou envahissante. Ce n’est pas non plus évident qu’il s’agit d’une barre de progression, jusqu’à ce qu’on ait terminé quelques processus multi-étapes. Notez également que vous pouvez faire des détours ; vous pouvez faire quelque chose en parallèle, comme enregistrer une équipe ou enregistrer un schéma directeur, et ces détours ont leur propre indicateur de progression qui est distinct du principal.

Nous avons récemment fait un « sprint » important qui a réunit toute l’équipe de Launchpad pendant deux semaines au cours desquelles nous nous sommes profondément immergés dans JavaScript et Ajax. Nous avons choisi YUI 3, la prochaine version de la librairie d’interface utilisateur pour le Web de Yahoo, comme fondation pour ce travail avec Ajax, et nous voulions que tout le monde soit opérationnel pour accélérer les processus de conception, de réalisation et de test d’applications clientes Web. Ce fut très plaisant.

Nous voulions, en particulier, unifier l’interface de programmation applicative pour services Web que nous avions déjà publié avec ce travail sur Ajax, pour qu’il soit facile d’écrire du code pour navigateur qui puisse communiquer avec l’interface de programmation applicative telle que nous l’avons mise à disposition des développeurs qui intègrent Launchpad. C’est maintenant possible, ce qui signifie que toute interface de programmation applicative que nous utilisons pour travailler avec Ajax pourra aussi être utilisée par les développeurs qui écrivent leurs propres outils pour accéder à Launchpad directement au travers de services Web.

Grâce aux atouts de YUI 3, l’équipe travaille maintenant d’arrache-pied pour faire passer ces idées du rêve à la réalité. Étant donné que YUI 3 est un projet d’avant-garde (certains diraient à l’avant garde !) nous nous concentrons sur les parties qui ne dépendent pas de widgets complexes – celles-ci commenceront à être en place l’année prochaine lorsque YUI 3 sortira de sa phase de développement.

Au cours des deux prochains mois vous verrez arriver des pièces de ce puzzle dans les versions mensuelles successives de Launchpad (ou quotidiennement, si vous êtes sur edge.launchpad.net et bêta testeur). Dans un premier temps, l’effet Ajax permettra juste l’édition en ligne. Dans six à neuf mois, les parties les plus complexes devraient être en place. Et d’ici là l’interface Web frontale de Launchpad sera aussi Open Source.

Source : Morphing dialogs and the AJAX roadmap for Launchpad

Certains des commentaires sur mon dernier billet à propos du ralentissement économique de 2008 ont suggérés que des gens pensaient que nous assistions à la fin du capitalisme et au début d’une nouvelle ère socialiste.

J’ose espérer que non.

Je pense en effet qu’un monde sans capitalisme régulé serait morne. J’ai eu le grand privilège de séjourner un an en Russie en 2001/2002, et la preuve visible de la destruction causée par la planification centrale était encore très présente. En fin de compte nous sommes tous humains, avec des défauts humains, que nous travaillions pour une agence de planification de l’État ou pour une entreprise privée, et ces défauts ont forcément des conséquences. De là à penser que mettre toutes les entreprises privées dans les mains de l’État serait la panacée en matière d’efficacité et de durabilité reviendrait à ignorer les tristes leçons du 20ème siècle.

Les dirigeants et les décideurs d’une économie centralisée sont tout aussi faillibles que ceux d’une économie capitaliste – ce seraient probablement les mêmes personnes ! Mais il manque aux  entreprises d’État les potentiels d’évolution qui s’appliquent dans une économie capitaliste – les entreprises d’État ont rarement, voire jamais, le droit à l’échec. C’est ce qui fait que de mauvaises idées sont perpétuées indéfiniment et qu’une économie dysfonctionne au point d’arriver à un effondrement systématique. C’est un fait que les entreprises privées qui font faillite dynamisent les industries. La tension entre l’impératif d’innover et les conséquences des échecs poussent les économies capitalistes à évoluer rapidement. Malgré toutes les conséquences désagréables que nous avons vu, et celles que nous avons encore à voir, concernant la mauvaise santé du capitalisme, je suis fermement convaincu que la société doit puiser dans ses forces capitalistes si elle veut avancer.

Mais j’ai choisi mes mots avec précaution quand j’ai dit « capitalisme régulé ». J’étais un grand fan de la main invisible de Adam Smith et grand admirateur de la vision de Ayn Rand’s. Maintenant, je vois les choses différemment. Livré à lui-même, le marché aura tendance à renforcer la position de ceux qui ont réussi dans le passé, et à l’exclusion de ceux qui pourraient créer des succès futurs. Nous voyons des preuves de ceci tout le temps. Les poids lourds qui régissent une industrie ont tendance à faire tout ce qui est en leur pouvoir pour empêcher l’innovation de changer les règles qui les enrichissent.

Un exemple classique est le comportement de la RIAA – au nom de la « sauvegarde de l’industrie musicale » ils ont passé les dix dernières années à essayer désespérément de la maintenir dans l’ère analogique pour sauver ses membres, avec le DRM et un lobbyisme moralement injustifiable autour des règles du droit d’auteur qui concernent l’ensemble de la société.

De la même manière, les règles sur les brevets ont tendance à évoluer pour s’adapter aux entreprises qui détiennent de nombreux brevets, plutôt qu’aux personnes qui pourraient révéler la PROCHAINE vague d’idées innovantes.  Bien sûr, le lobbyisme est habillé d’un discours qui le décrit comme étant « dans l’intérêt de l’innovation », mais au fond il est réellement destinée à préserver la position privilégiée de celui qu’il dessert.

En Afrique du Sud, l’opérateur téléphonique en situation de monopole, qui était une entreprise d’État jusqu’à ce qu’il soit partiellement privatisé en 1996, a systématiquement retardé, interféré, contesté et entravé le processus naturel de déréglementation et la création d’un secteur concurrentiel sain.  Les intérêts privés agissent dans leur propre intérêt, par définition, ce qui fait que les intérêts privés puissants ont tendance à orienter le système pour qu’ILS se portent bien, plutôt que de faire ce qu’il faut pour que la société aille bien.

Livrées à elles-mêmes, les entreprises privées auront tendance à se manger entre elles, et à créer des monopoles. Ces monopoles saperont ensuite le moral de tout nouvel arrivant, en utilisant toutes les tactiques qu’ils pourront imaginer, du FUD à la pression ou à la violence.

Je suis donc un fan du capitalisme régulé.

Nous avons besoin d’une réglementation pour nous assurer que tous les besoins de la société, comme la durabilité de l’environnement, soient satisfaits pendant que les entreprises privées font des profits.  Nous avons également besoin de réglementation pour nous assurer que ceux qui gèrent les infrastructures nationales et internationales, qu’il s’agisse de voies ferrées, de centrales électriques ou de systèmes financiers, ne manipulent pas les chiffres d’une manière qui leur permette de déclarer des profits juteux et des primes bien grasses alors qu’ils mènent ces systèmes à la crise.

Mais réguler efficacement n’est pas la même chose que gérer et surveiller un État. Je préfèrerais nettement qu’il y ait des sociétés privées pour gérer les centrales électriques de manière concurrentielles, plutôt que cela soit fait par des agences d’État qui participent complaisamment à un monopole gouvernemental.

C’est très difficile de bien réguler. Au fil des années, j’ai dialogué avec différentes autorités de régulation et je me suis familiarisé avec les problèmes qu’ils rencontrent.

Tout d’abord, il faut beaucoup de talent pour être un régulateur efficace. Et pour cela vous devez payer – le talent suit l’argent et les projecteurs, que vous le vouliez ou non, et concevoir un système sur d’autres hypothèses est le vouer à sa perte. Mon régulateur idéal est un génie perspicace qui travaille pour le bien commun, mais comme je ne rencontrerais probablement jamais cette personne, un objectif concret est d’encourager les régulateurs à être petits mais très bien financés, avec des salaires et des mesures de performance qui soient alignés sur les industries qu’ils sont censés réguler. Les régulateurs doivent pouvoir être licenciés – cela n’a pas de sens d’offrir à quelqu’un un salaire du secteur privé et une responsabilité du secteur public. Malheureusement, la plupart des régulateurs finissent par aller dans l’autre sens, par le recrutement de plus en plus de personnes ayant une compétence moyenne, qui deviennent à la fois coûteuses et inefficaces.

Deuxièmement, un bon régulateur doit être indépendant. Vous êtes le type qui dit aux gens d’arrêter de faire ce qui nuira à la société ; c’est très difficile de faire ça avec ses amis. Le travail de régulation est un travail de solitaire, c’est pour ça que vous entendez autant d’histoires sur des régulateurs avinés et nourris par les industries qu’ils régulent seulement pour être sûr qu’ils ne regardent pas de trop près ce qui se passe dans les coulisses.  Un grand régulateur doit en savoir beaucoup sur une industrie, mais être indépendant de cette industrie. Encore une fois, mon idéal est quelqu’un qui s’est fait une bonne place dans un secteur, en connait les rouages, peut justifier son prix élevé, mais veut apporter une contribution à la société.

Troisièmement, un bon régulateur doit avoir du mordant. Cela a été très frustrant pour moi de voir le régulateur des télécommunications Sud Africain bloqué en justice par Telkom et entravé par l’impuissance du gouvernement. Les régulateurs doivent être capable de faire avancer les choses, ils doivent être en mesure d’influer sur la façon dont les entreprises se comportent, et ils ne peuvent pas   compter sur la persuasion morale pour y arriver.

Et quatrièmement, un régulateur doit prendre des décisions très difficiles concernant l’innovation, qui valent des décisions de capital-risque – pour prendre les bonnes, vous devez être capable de prédire l’avenir. Par exemple, quand une industrie change, comme changent toutes les industries, comment doit-on faire évoluer les règles ?  Quand un besoin nouveau pour la société est identifié, comme la nécessité de lutter contre le changement climatique rapidement et systématiquement, comment doit-on faire évoluer les règles ?  Les régulateurs doivent avancer aussi vite que les industries qu’ils contrôlent et ils doivent prendre des décisions concernant des choses que nous ne comprenons pas encore. Et même lorsque vous régulez, vous pouvez ne pas être en mesure d’arrêter une crise imminente.  Il est très facile de critiquer Greenspan pour le peu de régulation qu’il a fait sur les fonds de couverture et dérivés, mais ce n’est pas du tout évident pour moi que la régulation aurait fait une différence, je pense qu’elle aurait simplement déplacé l’ombre du système financier mondial vers l’étranger.

La régulation est donc extrêmement difficile, mais cela vaut vraiment la peine d’y investir si vous essayez de mettre en place une société saine, dynamique et capitaliste.

Pour en revenir à la suggestion initiale qui a déclenché ce billet – Je suis sûr que nous verrons échouer beaucoup de capitalistes dans le futur. Quelle horreur, je pourrais rejoindre leurs rangs, je ne voudrais pas être le premier ;-). Mais cela ne signifie pas la fin du capitalisme, c’est seulement une opportunité pour recommencer – plus intelligemment.

Source : This is not the end of capitalism

Avec Intrepid qui est aujourd’hui en voie d’être distribué via Internet je pensais que je pourrais parler un peu de notre démarche dans la conception des nouvelles interfaces pour le changement d’utilisateur, le gestionnaire de présence et la gestion de session, et des leçons que nous en avons retiré. Ted a bloggué à propos du travail qu’il a réalisé et cela a été repris dans quelques forums (rapidement récompensé par le titre mémorable de « new hotness »), mais dans la mesure où il s’agit de la première contribution de Canonical dans le domaine de l’interaction avec l’utilisateur je pensais qu’il serait intéressant d’en parler.

Voici une copie d’écran du résultat de ce travail :

La nouvelle applet FUSA vous permet de gérer votre présence, ainsi que de passer la main à un invité ou de changer d’utilisateur, et de se déconnecter

Dans l’une des premières sessions d’interaction avec l’utilisateur, nous avons examiné plus en détail la façon dont les gens « arrêtaient de travailler ». Nous avons pensé intéressant d’essayer de regrouper ces actions de manière à ce qu’elles paraissent naturelles aux utilisateurs.

Nous avons déjà travaillé sur ce thème dans Ubuntu – pendant longtemps nous avons eu un bouton dans le coin supérieur droit du tableau de bord qui affichait une boîte de dialogue modale donnant accès aux options classiques pour « terminer votre session » telles que la déconnexion, le redémarrage, l’arrêt, l’hibernation, la suspension et le changement d’utilisateur. Ce patch a toujours été un peu controversé et n’a pas été accepté en amont, ce qui fait que nous avons cherché des moyens de résoudre le problème différemment.

Nous avons décidé d’utiliser l’emplacement en haut à droite, parce que c’est l’une des zones privilégiées de l’écran à laquelle il est rapide et facile d’accéder (vous pouvez déplacer votre souris vers un coin de l’écran très facilement et avec précision) et parce qu’il y avait une forte habitude du vieux bouton de déconnexion de Ubuntu.

Une idée clé est que nous voulions rendre le « changement d’utilisateur » moins complexe et plus direct – nous voulions permettre aux gens de passer directement à l’utilisateur spécifique qui les intéressait plutôt que d’avoir une étape intermédiaire où ils se connectaient sous cet autre utilisateur. Nous avons donc démarré avec l’Applet de changement rapide d’utilisateur (« Fast User Switcher Applet »), ou FUSA, comme point de départ de la conception. Une autre idée clé qui est apparue fut que nous voulions intégrer la « gestion de présence » dans le même menu, car « passer hors ligne » ou « Je suis occupé » sont des états ou des tâches similaires à « fermer la session » ou « éteindre ».

Ordre du menu

Nous avons longuement discuté de l’ordre idéal pour les éléments du menu. D’un côté, mettre les «  autres utilisateurs » en haut du menu impliquait que tous les noms d’utilisateurs – les vôtres et ceux vers lesquels vous pouvez aller – seraient visibles « au même endroit » en haut du menu. De l’autre, nous avions vraiment le sentiment que les choses qui allaient être utilisées de manière banale et plus facilement devraient se trouver en haut. Au final nous avons décidé de placer les options de gestion de présence en haut (Disponible, Absent(e), Occupé(e), Hors ligne). Juste à côté d’elles (dans le même groupe) nous avons mis l’option « Verrouiller l’écran », car elle s’apparente plus à un réglage de présence qu’à un paramètre de gestion de session – vous affichez « Absent(e) » plus souvent que le reste.

Ted a beaucoup travaillé pour rendre les éléments du menu présence compatibles avec Pidgin et Empathy car il y avait quelques incertitudes concernant lequel serait utilisé par défaut dans la version. Dans la mesure où il D-Bus, cela devrait être simple de le faire fonctionner également avec les clients de messagerie instantanée de KDE.

Nous avons ensuite ajouté les options pour le changement d’utilisateur -  dont la « Session d’invité » qui est une nouvelle fonctionnalité pratique de Intrepid au sujet de laquelle on a beaucoup bloggué (regardez la démo YouTube) et qui utilise AppArmor pour renforcer la sécurité.

Enfin, les options de clôture de session – Fermer la session, Suspendre, Hiberner, Redémarrer et Éteindre sont en bas du menu, parce que vous êtes sensé les utiliser une seule fois par session, par définition !

Création

La conception du menu est délibérément sobre. Nous utilisons des couleurs et des formes très simples pour les indicateurs de présence, et nous réutilisons ces couleurs et ces formes dans le tableau de bord de GNOME de sorte que vous puissiez voir d’un seul coup d’œil qu’elle est l’état de votre indicateur de présence. Je pense que Ted a rencontré quelques difficultés pour aligner les icônes de présence du menu avec l’indicateur de présence actuel qui est situé dans l’applet du tableau de bord, mais il s’en est bien sorti. Il reste encore du travail à faire pour finaliser la présentation mais il n’a pas pu être terminé a temps pour la version, cela devrait faire l’objet d’un mise à jour stable (SRU) ou se trouver dans Jaunty.

Nous avons décidé de ne pas mettre d’icônes dans le menu pour chacun des états. Notre méthode de conception à pour but de proposer des présentations plus sobres, moins chargées d’icônes et avec des textes mieux choisis. Deux ou trois personnes ont dit que le menu était « clairsemé » ou « dépouillé » mais je pense qu’il va dans le bon sens et nous continuerons dans cet esprit lorsque nous aborderons d’autres parties du systèmes.

En amont

Ce travail a été discuté lors de l’UDS à Prague avec un certain nombre de personnes de la communauté GNOME. J’ai également été très heureux de constater pendant la Hackfest de GNOME qu’il y avait une forte demande pour un tableau de bord plus réduit et plus simple, et l’idée que nous avons eu à beaucoup plu. L’applet FUSA elle-même est remontée en amont après quelques modifications car elle a été fusionnée dans le nouveau code de GDM et le vieux code – sur lequel notre travail s’appuie – est plus ou moins en fin de vie. Mais nous avons trouvé comment mettre à jour ce travail pour Jaunty et à partir de là il sera plus facile de le faire remonter.

Dans Jaunty, nous travaillerons probablement sur le tableau de bord de GNOME, en nous basant sur les discussions autour de l’utilisabilité de GNOME. Concernant le peaufinage du tableau de bord, il y a eu beaucoup de discussions que nous devrions poursuivre.

Intégration dans Ubuntu

Nous avons réalisé assez tard dans le cycle de Ubuntu que nous n’avions pas beaucoup pensé au paquet pour la distribution. L’équipe de Ubuntu a gentiment offert son aide pour concevoir le paquet et intégrer l’applet mais nous avons bien compris l’importance de préparer les paquets plus tôt que trop tard. Nous avons mis l’applet dans le PPA suffisamment tôt pour le test entre développeurs, mais nous avons sous-estimé la différence entre ça et l’intégration effective dans la version.

L’équipe de Ubuntu s’est ralliée à notre cause et nous a aidé à faciliter le processus de mise à jour pour les nouveaux utilisateurs, de sorte que nous puissions essayer d’avoir tout le monde sur un pied d’égalité lors du passage à Intrepid, que ce soit par le biais d’une nouvelle installation ou bien d’une mise à niveau. Il y a eu cependant quelques défis à relever, car le tableau de bord est tellement personnalisable, et nous devions beaucoup réfléchir sur la manière de procéder pour nous assurer que l’on conservait une utilisation consistante pour des choses aussi importantes que la fermeture d’une session ou l’arrêt du système tout en essayant de ne pas empiéter sur les préférences des personnes qui avaient personnalisé leur tableau de bord. De la même manière, nous étions  préoccupés par le fait que des personnes utilisant différentes versions de Ubuntu, ou différentes distributions, avec le même répertoire utilisateur, puissent avoir des problèmes si ces systèmes d’exploitations ne disposaient pas de la même version de FUSA – nous n’étions pas vraiment capable de gérer cela de manière satisfaisante.

Nous avons aussi réalisé (D’oh!) que nous n’avions pas vu le processus d’intégration dans son ensemble, car nous n’avions pas trouvé ce qu’il fallait faire avec les options du vieux menu Système. Il s’est avéré qu’elles étaient en passe d’évoluer, avec les gens de Ubuntu qui avaient à choisir entre le GNOME par défaut actuel que chacun disait vouloir changer, les correctifs pour l’approche probable du PROCHAIN GNOME, et la vieille approche de Ubuntu. Ted a préparé en vitesse des correctifs pour rendre le tableau de bord de GNOME plus souple avec ses menus, de sorte que nous puissions supprimer les vieilles options de fermeture de session du menu Système lorsque les gens avaient le même menu dans l’applet FUSA, mais c’est arrivé trop tard pour être inclus dans la version finale de Intrepid.

Somme toute, je pense que c’est un beau travail et j’espère que d’autres distributions le trouveront  utile. C’est juste une babiole en rapport avec le travail que nous prévoyons de réaliser dans le cadre de l’utilisation du bureau. J’ai hâte de retrouver tout le monde à l’UDS de Jaunty à Mountain View en décembre, quand nous pourrons parler de la prochaine étape ! Merci et bravo à Ted, Martin, Scott, Sebastien et tous ceux qui ont aidé à ce que ceci devienne une réalité.

Bravo à l’équipe Ubuntu (des milliers de personnes chez Ubuntu, Debian et en amont) qui on rendu possible cette magie dans 8.10. Heureux « Release Day » à tout le monde !

Source : Ibex design: user switching, presence and session termination

Le hackfest sur l’interaction des utilisateurs avec GNOME qui s’est déroulé à Boston était une bonne façon de passer la pire semaine dans l’histoire de Wall Street !

Même s’il n’y a pas eu beaucoup d’action, il y a eu BEAUCOUP de discussion et nous avons parlé de nombreuses choses. Il y avait au moins 7 personnes de Canonical, ce qui fait que c’était un peu comme une réunion de travail doublée d’une belle occasion pour rencontrer l’équipe. Il y a eu une importante participation de plusieurs organisations et esprits libres, et un désir partagé de voir GNOME rester au premier plan en terme d’utilisabilité.

Neil Patel de Canonical a regroupé quelques prototypes d’interfaces utilisateur pour essayer de capturer l’esprit de ce qui était discuté, mais je pense que la partie la plus intéressante ne pouvait pas vraiment être saisie par une capture d’écran car elle était abstraite et conceptuelle – gestion de fichiers et de contenu. Une révolution se profile alors que nous sommes en train de délaisser la vieille métaphore des “fichiers et dossiers” pour passer à quelque chose de nouveau, et ce serait extraordinaire si le logiciel libre montrait la voie.

J’ai été frappé par le nombre de manières différentes à partir desquelles le concept a surgit. Nous avons eu une superbe présentation de “problèmes de support réels” provenant d’un important utilisateur de postes de travail sous Linux, et un thème récurrent fut : “où diable est donc passé ce fichier ?”. Les gens sauvegardent une pièce jointe qu’ils reçoivent dans un courriel, et une heure plus tard ils n’ont aucune idée de l’endroit où elle se trouve. Ils importent une image dans F-spot et ensuite ils ne savent pas comment faire pour la joindre à un courriel. Ils téléchargent un fichier PDF depuis le Web, puis ils veulent le lire hors-ligne et n’arrivent pas à se souvenir de l’endroit où ils l’ont mis. Quelqu’un à fait remarquer que la plupart des gens trouvaient plus facile de trouver quelque chose sur Internet – via Google – que sur leurs disques durs.

Les personnes de chez Codethink ont également présenté un travail expérimental fait avec Wizbit, un système de contrôle de version reposant sur un fichier unique et s’appuyant sur Git et Bazaar, pour imaginer comment vous pourriez gérer de manière efficace et transparente les versions d’un fichier pour l’édition en ligne et hors-ligne.

Nous devons ré-architecturer la façon de “travailler avec vos contenus” et nous devons le faire pour que cela fonctionne avec le Web et les contenus partagés aussi facilement qu’en local.

Ma plus grande préoccupation à cet égard est que les choses soient faites de sorte que tout environnement de bureau puisse les adopter. Nous avons besoin d’une interaction cohérente entre GNOME, KDE, OpenOffice et Firefox afin que les contenus puissent passer d’une application à l’autre de manière simple et que les attentes des utilisateurs puissent être satisfaites indépendamment des applications ou des environnements qu’ils utilisent. Si quelqu’un m’envoie un fichier via Empathy, et que je veux l’ouvrir dans Amarok, il ne faut pas que j’ai à prendre en compte deux visions complètement différentes du stockage de contenu. De la même manière, si j’ai téléchargé quelque chose depuis le Web avec Firefox, et que je veux l’éditer dans OpenOffice, il ne faut pas que j’ai besoin d’être super-branché ou super-intelligent pour être capable de relier les applications au contenu.

Donc, à mon avis ce travail devrait être défendu dans un forum comme FreeDesktop.org, où il pourrait s’élever au-dessus des rivalités qui existent autour du poste de travail sous Linux. Il y a une bonne pratique de la collaboration concrète dans ce forum, et ce travail est un très bon candidat pour ce type d’approche.

À la fin de la journée, il s’agissait moins d’une transformation que d’un changement fondamental dans la gestion de contenu. Félicitations aux personnes qui font bouger tout ça !

Source : GNOME usability hackfest

L’expression “resserrement du crédit” est très trompeuse concernant la crise actuelle. Elle suggère qu’il s’agit simplement d’un problème de confiance, que le calme reviendra si des liquidités sont injectées dans le système.

Mon point de vue, cependant, c’est que le vrai problème est un problème de solvabilité. C’est la faillite systémique de 2008.

Les prêts hypothécaires ne sont que le début.

À des taux d’intérêt réels, avec de vraies attentes d’un taux de rentabilité raisonnable, la plupart des opérations qui ont été faites depuis 2003 n’ont pas de sens économique. Jusqu’à présent, l’accent a été mis sur une partie du problème – les mauvais prêts hypothécaires – mais je pense que nous allons rapidement voir surgir de nouvelles zones problématiques parmi lesquelles figureront les transactions sur les titres non cotés faites sur la base de l’argent gratuit, entre 2003 et 2007. Je me souviens d’une déclaration stupide de certains génies des titres non cotés disant que “tout le monde se presse pour faire la première opération à 100 milliards de dollars”. Et bien, ils se sont se sont cassés le nez. Attendez-vous à un flot régulier d’annonces d’échecs, de restructurations et de faillites car les sociétés qui ont été achetées avec de l’argent emprunté ne seront à leur tour pas en mesure d’honorer de leurs dettes.

Des taux d’intérêts plus bas n’atténueront que les symptômes.

La réduction spectaculaire des taux d’intérêt contribuera à ralentir le rythme auquel nous devrons faire face aux faillites, mais elle ne changera pas la froide réalité de la situation, et elle risque bien de faire empirer les choses en encourageant une autre série de spéculations basées sur l’argent gratuit. Nous sommes une fois de plus dans une situation où le taux d’escompte des États-Unis est en fait un taux d’intérêt réel négatif, comme un cadeau aux banques, mais quelle que soit la durée, y rester nous remettra dans un état de dépendance.

Les interventions doivent cibler les fonds et la force des banques, pas les liquidités.

Je pense que la dernière action du Royaume-Uni visant à acheter des participations est pour l’instant la meilleure réponse. Elle améliore de façon spectaculaire la capitalisation de ces institutions, elle met le bénéfice de cette hausse dans les mains des contribuables (ils supportent les difficultés et le financement du renflouement, il paraît juste de les faire profiter du résultat) et elle dissout les actionnaires existants qui ont permis à leurs institutions de devenir insolvable. Personnellement, je serais enclin à faire plus que de diluer ces actionnaires.

Je ne vois pas que la transaction actuelle de 700 milliard de dollars fera une réelle différence pour les banques américaines. Je m’attends à ce que les États-Unis annoncent bientôt une action similaire à celle du Royaume-Uni, mais les chiffres devraient être plus importants. Dans une proportion inquiétante. Il vaut bien mieux pour les États-Unis qu’ils fassent cela, plutôt que d’attendre que des pays d’Asie et du Moyen-Orient s’engouffrent dans la brèche.

Ceux qui font des dépôts dans des banques réglementées devraient être protégés par les gouvernements qui gèrent les autorités de régulation. Les actionnaires moins. Les porteurs d’obligations … peut-être.

Je pense que l’Irlande et les autres pays qui ont garanti les dépôts individuels ont fait la bonne chose. Les gouvernements mettent en place des autorités de régulation, et les banques font de la publicité pour faire savoir qu’elles sont réglementées. Les personnes qui nomment ces régulateurs doivent soutenir leur approche – ils doivent offrir la garantie qu’ils soutiendront leur produit, et s’il est défaillant, qu’ils soutiendront ceux qui leur ont fait confiance. Ceux qui font des dépôts dans des banques du Royaume-Uni ne doivent pas craindre que ces banques puissent faire faillite – ce type de faillite doit au pire affecter le taux d’intérêt qu’ils reçoivent, pas l’intégrité de leur capital. Les actionnaires de ces banques devraient par contre être très inquiets. Une question intéressante se pose pour les porteurs d’obligations et les déposants institutionnels. D’un côté ce sont des investisseurs avisés et ils devraient être responsables de leurs obligations. D’un autre côté, ce sont les seuls qui peuvent provoquer des mouvements de fonds massifs en valeurs mobilières ou en bons du trésor, il est par conséquent préférable de les ménager. Je les mettrais donc aussi avec les déposants individuels.

La rémunération des dirigeants devraient être structurée, pas fixe.

Il y a eu beaucoup de discussions sur la limitation de la rémunération des dirigeants. C’est juste une invitation pour des armées de consultants, d’avocats et de comptables à travailler autour de ce que sont les limites des rémunérations misent en place. Et franchement, j’ai du mal à comprendre comment les hommes politiques, qui se votent constamment des salaires et des comptes de dépenses toujours plus gros, sont qualifiés pour fixer les salaires des dirigeants de banques. Ils ÉTAIENT responsables de la rémunération des dirigeants de Fannie et Freddie, et ce ne fut pas un brillant succès.

Ce que je dirais, cependant, c’est que les gains de l’institution financière ne devraient être reconnus qu’après une période de sept ans, et les primes basées sur ces revenus devraient être gardées en dépôt jusqu’à ce que cette période de sept ans soit terminée. Imaginez si l’on pouvait maintenant puiser dans les primes acquises par des employés des banques d’investissement au cours des sept dernières années afin de renforcer les bilans de ces banques. Cela inclurait les primes versées à M. Fuld, M. Greenberg et M. Greenspan. Quelqu’un veut faire les comptes ? Je pense que ce serait important.

Je suis nerveux.

La grande question que je pose est de quel côté n’y-a-t’il pas de mines ? Mon équipe et moi-même avons eu la chance de sortir de nombreux marchés avant le déferlement de crainte actuel. Nous avons eu quelques problèmes, mais nous avons évité les boulets de canons. Jusqu’ici tout va bien. Mais que signifie avoir de l’argent à la banque, lorsque les banques elles-mêmes font faillite ? Que signifie avoir des dollars, quand le dollar est dévalorisé dans des proportions familières à la Reserve Bank of Zimbabwe ? Ce sont des moments très dangereux, et personne ne devrait penser autrement.

Source : It’s a solvency problem, not a liquidity problem

Lorsque vous vous présentez sur le Web, vous avez 15 secondes pour faire bonne impression, d’où la convergence des champions en herbe de l’industrie du Web 2.0 vers la recette du succès suivante :

1. Rendez votre site visuellement attrayant,
2. Faites quelque chose de différent et faites-le très, très bien,
3. Mobilisez les utilisateurs et offrez-leur une expérience immédiate, gratifiante.

Dans l’utilisation du logiciel libre, nous avons besoin des mêmes célérité, immédiateté et élégance, et c’est un domaine dans lequel Canonical, je l’espère, apporte une contribution significative. Nous recrutons des designers, des champions de l’expérience utilisateur et des visionnaires du design de l’interaction que nous plaçons non seulement à la tête de différents projets chez Canonical mais que nous poussons également à participer à GNOME, KDE et autres projets en amonts, pour améliorer l’utilisabilité des FLOSS.

Heureusement, nous ne travaillerons pas seuls. C’est une idée qui a déjà largement été explorée. C’est génial de voir que des communautés comme GNOME et KDE ont identifié l’expérience utilisateur comme un puissant vecteur d’évolution pour leurs plates-formes. En partie liée au phénomène du Web 2.0 et de l’iPhone, il y a une volonté partagée de voir les FLOSS faire un bon en avant en terme d’utilisabilité et de design. Nous voulons participer et aider à cette avancée.

L’ampleur du défi que nous avons à relever est reconnue. Lorsque j’ai annoncé à l’OSCON, l’objectif de “fournir une expérience utilisateur qui puisse rivaliser avec celle d’Apple dans deux ans”, j’ai eu de nombreuses questions relatives à la façon dont nous pourrions bien nous y prendre pour y parvenir. “Tout le monde se gratte là ou ça le démange, comment pourrez-vous rendre l’interface utilisateur cohérente ?” fut une interrogation récurrente. Et c’est vrai – le logiciel libre est souvent parcellaire et inconsistant. Mais je vois le manque de consistance autant comme une faiblesse (GNOME, OpenOffice et Firefox ont tous des bibliothèques différentes pour le développement d’interfaces utilisateur, et il est très difficile de les accorder) que comme une force – les gens sont libres d’innover, et les résultats font référence au niveau mondial. Notre objectif est d’arriver à de tirer le meilleur de ces deux mondes.

Je n’ai pas de réponses à toutes ces questions. J’ai crois cependant beaucoup en la puissance du processus d’élaboration du logiciel libre pour résoudre des problèmes apparemment insolubles, en particulier sur le long terme. Si nous combinons une vision globale de la conception avec de nouvelles recommandations pour les interfaces utilisateur, nous pourrons nous appuyer sur l’expérience des utilisateurs pour trouver des cas particuliers et des inconsistances dans un plus grand nombre d’applications que ne pourrait le faire une personne ou une seule société. C’est pour cela qu’il est si important pour moi que l’équipe design et interface utilisateur de Canonical participe aussi aux projets en amont.

Dans Ubuntu nous avons toujours eu tendance à considérer les projets en amonts comme “notre ROC”, sous tendant que nous souhaitions que les équipes des projets en amonts soient heureuses de la manière dont nous exprimons leurs idées et leur travail. Plus que heureuses – nous voulons que les équipes des projets en amonts soient enchantées ! Nous concentrons principalement notre effort sur l’intégration. Nos concurrents ont tendance à dire que “Canonical ne contribue pas” mais il serait plus juste de dire que nous mesurons notre contribution dans l’efficacité avec laquelle nous mettons les derniers développements des projets en amonts, en maintenant la sécurité, à la portée de la plus large audience possible pour qu’elle les teste et les adore. À mon avis, c’est une énorme contribution.

Canonical est cependant de plus en plus en situation d’induire un vrai changement dans le logiciel qui constitue Ubuntu. Si nous avions juste montré des images et des prototypes en demandant aux gens de remodeler leur projets, je n’imagine pas que cela aurait été bien reçu ! Nous sommes donc en train de recruter une équipe qui travaillera sur X, OpenGL, Gtk, Qt, GNOME et KDE, avec comme objectif de réaliser une partie du travail important qu’il faut faire pour donner naissance à ces idées. Ces équipes publieront leurs branches Bzr dans Launchpad et soumettrons bien sûr leur travail en amont, et elles participeront aux divers évènements associés aux projets en amont. Certaines personnes que nous avons recruté à ces postes sont des contributeurs familiers du monde FLOSS, d’autres seront des développeurs ayant des compétences techniques avérées dans d’autres industries.

Un principe fort que nous voulons préserver est l’idée que Ubuntu, l’équipe travaillant sur la plate-forme, est principalement concentrée sur l’intégration et la distribution. Nous maintiendrons bien la séparation entre cette équipe et le travail réalisé en amont afin de minimiser tout conflit d’intérêt dans le choix des correctifs, des modifications et des applications qui sont livrés chaque six mois dans le cadre d’une version de Ubuntu.

Évidemment, il y a un risque à participer, car vous ne pouvez pas facilement participer sans exprimer vos opinions, visions, désirs, buts, et ceux-ci peuvent entrer en conflit avec ceux des autres participants. C’est difficile de mener à bien le changement, même lorsque les gens sont d’accord sur la nécessité de ce changement. J’espère que nous pourrons trouver des façons d’explorer et d’expérimenter de nouvelles idées sans provoquer de blocage au sein d’équipes diverses et distribuées. Nous devons utiliser nos atouts, en particulier la capacité de diverger à des fins d’expérimentation pour voir ce qui fonctionne vraiment avant de mettre tout le monde au travail. Ce sera un défi, mais je pense que c’est faisable.

Tout ceci fait que je vais travailler avec entrain le matin, car nous sommes esquissons des idées tout à fait intéressantes qui touchent à l’interaction de l’utilisateur dans Launchpad et sur le poste de travail. L’équipe s’entend très bien, et j’apprécie beaucoup la manière dont les choses se passent, la réflexion et le prototypage. Je suis impatient de voir ces idées arriver au stade de la production !

Source : Design, user experience and development at Canonical

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.

Source : Economic clustering and Free Software release coordination

Une distribution occupe une niche très particulière dans l’écosystème du logiciel libre. Entre autres choses, nous devons accepter une certaine responsabilité pour TOUS les défauts logiciels (”bogues”) que les utilisateurs rencontrent dans l’ensemble de la distribution. La plupart des utilisateurs n’installent pas leurs applications à partir des sources disponibles en amont, ils les installent à partir des paquets présents dans leur distribution. Donc lorsqu’ils ont à faire à une bogue, ils ne savent pas s’il s’agit d’une bogue introduite par la distribution, ou une bogue dans le code source sous-jacent. Ils ne savent pas, ils s’en moquent, et effectivement, ils n’ont pas à s’en préoccuper. Ils remontent généralement l’erreur à l’éditeur de leur distribution, et la manière dont nous répondons est importante, car c’est une occasion de consolider tout l’écosystème.

J’avais un professeur qui était très opposé à l’utilisation du terme “bogues”. Il disait que le terme “bogue” était une gentille image pour un “vilain insecte”, et de manière similaire, les défauts logiciels sont potentiellement à même d’engendrer de sérieuses conséquences, ce qui fait que nous ne devons pas les traiter à la légère. Travailler sur les bogues est un travail sérieux, et c’est une des formes de contribution les plus importantes que Ubuntu puisse apporter au monde numérique, aussi je voudrais saluer les efforts extraordinaires de l’équipe de l’assurance qualité et des chasseurs de bogues. Des initiatives comme cinq-par-jour ont déjà induit une énorme différence pour nos utilisateurs. Comme le dit Henrik Omma, le rapport de bogue efficace nécessite une approche diligente et professionnelle et j’ai remarqué une réelle amélioration de notre communauté. Nous espérons pouvoir faire bénéficier tout l’écosystème du logiciel libre de cette compétence.

Ubuntu reçoit autant de rapport de bogues que OpenOffice, Mozilla, Gnome et KDE combinés. La majorité des bogues sont des problèmes qui viennent des versions en amont, ou de Debian. Notre premier objectif est de nous assurer que les correctifs que nous produisons, et que les informations que nous introduisons dans le processus d’assurance qualité, remontent bien vers les projets en amont où elles serviront à toute la communauté. D’un autre côté, nous voulons faire en sorte que chaque version de Ubuntu soit livrée sans défauts majeurs, indépendamment de l’origine de ces défauts. Nous sommes responsables des conditions d’utilisation de chaque ligne de code, même si nous ne produisons pas chaque ligne de code.

Au mois d’avril 2008, j’ai recensé les nombres bogues ci-dessous dans de grands projets FLOSS :

Avec du recul, avril était peut-être mal choisi, car c’était un mois de publication d’une version de Ubuntu qui va généralement avec une petite augmentation du nombre de bogues enregistrées. Il serait intéressant de voir les statistiques d’autres distributions, et projets, sur une année. Mais la tendance générale est claire – parmi nos familles de distributions, Ubuntu charrie le gros de la charge relative au suivi des bogues, au tri et à la gestion des correctifs – non seulement pour les utilisateurs, mais pour une grande partie du logiciel libre utilisé.

Quand j’ai fouillé dans les données pour voir comment nous remontions les bogues en amont, j’ai découvert quelque chose d’assez mitigé. Dans de nombreux cas, nous le faisons effectivement très bien. Nous avons par exemple une très bonne relation avec GNOME, avec très haut pourcentage de bogues relayés vers le gestionnaire de bogues en amont. Dans d’autres projets, il est difficile de donner un point de vue définitif. Le pourcentage varie selon que les membres de l’équipe de Ubuntu ont de bonnes relations avec les projets en amont, ou qu’une personne fasse l’ambassadeur de Ubuntu auprès du projet en amount (c’est super pour faire la différence si vous portez une attention particulière à une application dans Ubuntu !) ou que le projet en amont y trouve lui-même son intérêt.

Nous devons améliorer les outils qui permettent de gérer ce types d’échanges entre projets. Launchpad nous permet actuellement de suivre l’état d’une bogue dans de nombreux gestionnaires de bogues, et il commence à y avoir pas mal de distributions et de projets en amont qui utilisent soit Launchpad directement ou qui échangent efficacement des informations. Nous continuerons d’améliorer la qualité des échanges au sein de l’écosystème tout entier, y compris avec les projets qui n’utilisent pas Launchpad.

Source : Ubuntu’s role in bug management for the whole free software stack

C’est avec grand plaisir que j’ai vu comment Thawte a élégamment géré le problème apparu récemment dans le générateur de nombres aléatoires de OpenSLL sous Debian, Ubuntu et d’autres variantes de Debian. Ils ont offert une solution de remplacement gratuite à tous ceux qui étaient affectés. Des années en arrière, quand Thawte a été fondé, nous avons fait beaucoup d’efforts pour faire des choses qui aient du sens pour les utilisateurs de serveurs sécurisés basés sur du logiciel libre, comme ApacheSLL et ses semblables. Je n’ai pas suivi les changements intervenus dans la société depuis qu’elle a rejoint VeriSign en 2000, mais c’est super de voir que la marque a été préservée, et plus important, que certaines de ses valeurs fondamentales l’ont été aussi.

Source : Nicely handled, Thawte!

Vincenzo Ciaglia de Linux-Magazine Italie m’a envoyé quelques questions concernant la version 8.04 LTS. Comme il allait traduire l’entretien en italien cette semaine, il était content que je publie la version anglaise ici.

1) Salut Mark, merci pour votre disponibilité. Pour commencer, quelques questions simples pour vous présenter à nos lecteurs. Quel est votre rôle chez Ubuntu/Canonical et que faites vous durant votre temps libre ? Quels sont vos passes-temps ?

Mon sport favori est le surf des neiges et j’aime voyager sous les tropiques. Mais en fin de compte je suis plus heureux quand je fais le geek, je lis, je joue à des jeux ou je me détend avec des amis.

2) Vous êtes le fondateur de Canonical, la société qui édite Ubuntu. Pourquoi avez-vous décidé d’investir beaucoup d’argent (10 millions de $) dans une start-up ? Dans quels domaines travaille-t-elle ? Comment rendez-vous la société viable ?

La vision d’Ubuntu et de Canonical est symbiotique. Nous croyons que Linux est arrivé à un point où il est possible de concevoir la plate-forme pour un coût suffisamment bas de sorte qu’elle soit rentable simplement par les services associés, plutôt qu’en la vendant sous licence. En d’autres termes, nous pensons que l’assistance, la formation, les services en ligne et l’ingénierie professionnelle pour ceux qui veulent adapter Ubuntu commercialement, rapporteront assez d’argent pour payer Ubuntu lui-même.

Cela signifie que nous pouvons fondamentalement changer le modèle économique de l’industrie des systèmes d’exploitation. Bien sûr, il faudra du temps pour prouver que nous pouvons y parvenir, mais nous avons une superbe équipe et maintenant que Ubuntu est bien établi nous observons une augmentation de la demande des services chez Canonical, ce qui est positif.

3) Ok, parlons un peu de la dernière version 8.04 de Ubuntu. Dans un entretien vous avez dit “Hardy Heron est la version la plus significative jamais réalisée”. Bien, pouvez-vous parler des améliorations majeures de cette version ?

Premièrement, c’est une version LTS (”Long Term Support”) qui a été livrée en respectant un calendrier très précis. Six mois auparavant nous nous étions engagés à livrer la version 8.04 LTS le 24 avril et c’est exactement ce que nous avons fait. Autant que je sache, personne n’a jamais livré une version d’un système d’exploitation “d’entreprise” en suivant un planning aussi précis. Et non content de l’avoir fait, nous nous sommes maintenant engagé à livrer la prochaine LTS en avril 2010, ce sera la version 10.04 LTS et nous fixerons la date exacte six mois à l’avance comme nous l’avons fait pour celle-là. C’est grâce à Debian et à la communauté du logiciel libre que nous pouvons faire cela. La version 8.04 LTS a donc prouvé notre capacité à livrer dans les temps non seulement des versions supportées 18 mois, mais aussi des versions LTS. Nous espérons vraiment que d’autres distributions suivront notre exemple de cycle LTS avec leurs versions entreprise, car cela nous permettra de collaborer plus facilement et améliorera les principales distributions Linux.

Deuxièmement, il y de nouveaux développements très significatifs pour Ubuntu lui-même. Pour la version serveur, nous avons travaillé avec HP sur leur gamme Proliant et avec Dell sur leur gamme PowerEdge, pour nous assurer que la version 8.04 LTS serait compatible avec leurs serveurs x86. Nous ne sommes pas encore certifiés, mais nous sommes sûr que cela “Fonctionne”. Sun Microsystems est allé plus loin et a en fait certifié la version 8.04 LTS sur une gamme de serveurs x86. C’est un important pas en avant pour Ubuntu dans le monde du serveur. Nous constatons maintenant que Ubuntu est très utilisé sur les serveurs – c’est la plate-forme serveur la plus populaire chez plusieurs éditeurs de logiciel. Il est donc important que nous travaillions avec des vendeurs de serveurs et des vendeurs de solutions pour serveurs. Nous avons investi beaucoup de travail dans la mise en oeuvre de la virtualisation avec KVM et VMWare, parce que nous voyons que des gens fabriquent des centaines serveurs dédiés à la virtualisation sous Ubuntu.

Sur le poste de travail, nous avons mis l’accent sur la simplification de l’installation de Ubuntu, en particulier sur une machine déjà équipée de Windows, sur laquelle nous pouvons maintenant installer Ubuntu dans un fichier sur la partition Windows plutôt que d’avoir à redimensionner la partition Windows pour créer une nouvelle partition pour Ubuntu. C’est plus facile pour ceux qui veulent tester Ubuntu et avoir ainsi un avant-goût de ce qu’est le logiciel libre. Nous avons également travaillé sur plusieurs activités que les gens aiment faire avec leur PC, comme manipuler des photos ou faire de la musique et nous avons commencé à améliorer les choses pour l’utilisateur.

4) Il y a encore des problèmes matériels (en particulier avec certains périphériques sans-fil) sous Ubuntu. Comment pensez vous résoudre ce type de problèmes et améliorer la prise en charge du matériel dans les prochaines versions ?

Nous sommes de plus en plus apte à travailler directement avec les fabricants de matériels, pour essayer de les convaincre de développer des gestionnaires de périphériques libres pour leurs matériels. Nos relations avec différentes sociétés fabriquant des PC montrent que nous pouvons exercer, d’une manière convenable, une pression soutenue pour que les gens adoptent Linux.

Nous travaillons aussi très dur pour relier tous les affreux bouts de ficelle qui sont nécessaires pour rendre agréable l’utilisation de Linux sur votre machine. Malheureusement, il y a par exemple de nombreuses couches de gestion des liaisons sans-fil qui offrent des possibilités variées. Et Ubuntu dépense beaucoup de temps pour leur intégration et leur mise au point pour essayer de créer des conditions d’utilisations harmonieuses et standardisées pour les utilisateurs finaux.

5) Quel genre d’améliorations la version 8.04 de Ubuntu apporte-t-elle aux serveurs et aux solutions de virtualisation ?

L’édition serveur de Ubuntu reprend toutes les merveilleuses caractéristiques de Debian – il est modulaire, efficace, dispose d’un énorme choix de paquets, et il est très facile à installer et à administrer. De plus, nous avons beaucoup travaillé avec les fabricants de serveurs pour nous assurer de la compatibilité avec leurs matériels et nous avons commencé des certifications avec quelques uns d’entre eux.

Notre offre de virtualisation est basée sur KVM et VMWare. Tel quel, Ubuntu devrait vous donner toute satisfaction avec chacun d’eux. Ubuntu est optimisé et rigoureusement testé, et il est certifié sur la plate-forme serveur ESX de WMWare. KVM qui est l’option de virtualisation libre que nous préférons est intégré au noyau serveur standard. Il existe également un noyau Xen pour ceux qui préfèrent Xen.

Nous avons fait beaucoup pour l’intégration des serveurs Ubuntu et des réseaux Windows, en particulier dans le domaine de l’Active Directory et des serveurs de partage de fichiers SMB. Nous avons travaillé avec une société qui s’appelle Likewise pour être sur que le processus permettant de rejoindre un réseau Active Directory était correct et pouvait également permettre de gérer des machines Linux via l’AD en utilisant les outils professionnels de Likewise. Toutes les possibilités offertes pour réaliser les actions de base sont du logiciel libre et sont intégrées dans Ubuntu.

6) Une vilaine question venant de nos lecteurs : Ubuntu est vraiment un géant maintenant, essayez-vous de tuer le projet Debian ?

Absolument pas. Je suis moi-même un développeur Debian et je suis fier de ce que Debian a réalisé, et également fier de tout ce en quoi Ubuntu contribue au sein du projet Debian. Nous considérons que Ubuntu est un membre de la famille Debian, qui s’est juste axé sur les utilisations particulières et les plates-formes que veulent nos clients.

La majeure partie de ce que nous faisons dans Ubuntu sert directement à Debian. Nous supervisons le conditionnement de nombreux composants importants pour le poste de travail, le serveur, l’ensemble des outils, et nous apportons ce travail directement à Debian. En conséquence de quoi, Debian est maintenant mis à jour plus souvent qu’avant sans Ubuntu. Nous avons apporté de nombreux changements décisifs et nous essayons toujours de collaborer avec les bonnes personnes en amont ET chez Debian pour être sûr que tout ce passe bien dans ces projets. La plupart des DD (Debian Developer) sont très heureux de collaborer, mais certains perçoivent Ubuntu comme une menace, ou font des demandes déraisonnables pour Ubuntu parce qu’il pensent “vous avez de l’argent” alors qu’en fait Ubuntu est majoritairement basé sur le volontariat.

Ma vision est que Debian et Ubuntu deviendront de plus en plus fort grâce à une bonne collaboration. Je suis en train d’essayer de faire accepter une présentation à DebConf pour aider à transformer cette vision en réalité, mais jusqu’à maintenant je n’ai pas eu la chance d’avoir reçu l’accord. On espère, que ceux qui dirigent Debian vont commencer à admettre l’idée que le succès de Ubuntu est très bon pour Debian.

7) Vous travaillez avec des fabricants de systèmes embarqués et des sociétés d’électronique. De quelle manière ? Quel est votre travail dans le partenariat étroit avec Intel ?

Linux est de plus en plus utilisé par les fournisseurs de solutions embarquées et beaucoup d’entre eux veulent utiliser Ubuntu. Nous avons donc travaillé avec Intel pour être sûr que Ubuntu prenne totalement en charge leurs matériels (processeurs, chipsets, composants graphiques et autres).

8) Ubuntu est sûrement la distribution GNU/Linux la plus utilisée et la plus appréciée dans le monde. Mais, pensez-vous que Linux Ubuntu atteindra – un jour – le succès d’autres systèmes d’exploitation comme OS X et Windows ? De quelle façon pensez-vous accomplir un objectif similaire ?

Je pense vraiment que le logiciel libre sera largement reconnu, que l’on aura confiance en lui et qu’il sera utilisé par tous types d’utilisateurs, et ne sera pas réservé aux spécialistes comme c’est encore le cas. On espère que Ubuntu aura sa place, mais je ne pense pas qu’une plate-forme dominera l’ère du logiciel libre comme Windows à dominé l’ère des logiciels propriétaires. Ubuntu est axé sur des besoins spécifiques et il y a d’autres versions de Linux ou de BSD qui correspondent à d’autres.

Pour sortir du lot, nous devons offrir des conditions d’utilisations du poste de travail originales, qui soient simples à utiliser, et que les gens jugeront à même de répondre à leurs besoins futurs et à ceux de leurs collègues.

9) Tout le monde parle de GNU/Linux mais pour l’instant il ne semble pas que beaucoup de gens aient confiance en Linux (des statistiques rapportent que l’utilisation mondiale de Linux et de 0,xx %). Quel est le problème ? Ubuntu est pourtant vraiment un super système d’exploitation. Pensez-vous que c’est juste à cause d’une question de marketing ou parce qu’il y a une lacune au niveau des jeux ?

Je pense qu’il est temps de changer les habitudes de centaines de millions de personnes ! Je pense aussi que nous devons proposer quelque chose qui soit meilleur que tout le reste. Des projets comme Firefox ne se donnent pas pour objectif d’être “un bon navigateur”, ils disent “nous voulons être le meilleur navigateur sur toutes les plates-formes, un point c’est tout” et le résultat est qu’ils sont très populaires même sur Windows. Nous avons besoin de cette attitude gagnante partout.

10) Canonical a été la première société GNU/Linux à traiter avec un fabricant d’ordinateurs, Dell. Comment vont les affaires aujourd’hui ? La chose curieuse est que sur IdeaStorm beaucoup d’utilisateurs réclamaient des ordinateurs sous Linux mais après quelques mois il semble que les ventes ne sont pas bonnes, ou tout du moins pas autant qu’on l’espérait. Pourquoi ? GNU/Linux n’est peut-être pas encore prêt pour le marché du grand public ?

Je suis d’accord sur le fait que plus les gens achèteront des systèmes avec Linux pré-installé, plus des choses comme la prise en charge matérielle seront traitées rapidement. Heureusement, nous voyons déjà que des millions d’unités sont livrées avec Linux, pas seulement dans le domaine des PC haut de gamme. Le bas de gamme est très actif, surtout dans des pays comme le Brésil et la Chine. Doucement, Linux commence à faire du volume.

11) Travaillez-vous avec d’autres fabricants d’ordinateurs pour vendre d’autres machines de bureau ou des portables basés sur Ubuntu ? Nous sommes italiens et les ordinateurs Ubuntu-Dell n’arriveront jamais dans notre pays. Pourquoi Dell, et d’autres vendeurs, sont-ils aussi hésitants pour vendre des ordinateurs GNU/Linux dans le monde entier ?

C’est une simple question de demande et de coût pour la satisfaire. Tout constructeur de PC envisagera une opportunité d’un point de vue économique, et c’est bien qu’ils procèdent ainsi. Jusqu’à ce que les gens en Italie soient réellement décidés à acheter des ordinateurs avec Linux pré-installé, il n’y aura pas de vrai marché pour eux. Je suis sûr que des fournisseurs locaux qui assemblent des ordinateurs pré-installeront Ubuntu pour vous. Vous devez les aider à devenir suffisamment importants pour que les Dell, HP et Lenovo du monde soient convaincus qu’il y a une opportunité qui vaille la peine pour eux.

12) Quel est votre point de vue sur l’accord controversé Novell-Microsoft ?

Il y a de bonnes intentions, et il y a de mauvaises intentions, et malheureusement elles sont toutes mélangées dans cet accord. Le côté positif est qu’il est bon de voir Microsoft reconnaître que l’on a besoin de Linux et de Windows, et d’interopérabilité. Le côté négatif est que l’accord ne marche que financièrement car Novell et Microsoft ont le même modèle économique – vendre des licences de logiciels pour un certain prix par poste.

Microsoft est dans une situation délicate. Ils veulent à tout prix stopper l’utilisation gratuite de Linux et ils voudraient utiliser des brevets pour y arriver, ceci explique pourquoi ils ont structuré l’accord sur une “Licence de propriété intellectuelle” fictive. Mais ils savent aussi que les ingénieurs du logiciel libre pourront probablement se passer de tous les brevets qu’ils brandissent, c’est pourquoi ils sont assez réticents à faire état des brevets dont ils pensent qu’ils pourraient justifier un tel accord.

13) Dans un entretien (http://mybroadband.co.za/13nephp/?m=show&id=6672) vous avez déclaré que “vous seriez heureux de travailler avec Microsoft”. Voulez-vous faire un autre accord comme celui de Novell ou quoi ?

Je suis très heureux de travailler avec Microsoft, ou toute autre société, pour améliorer la situation du logiciel libre et de l’industrie du logiciel dans sa gobalité. Il y a de nombreuses choses sur lesquelles nous pouvons collaborer là où nous avons des intérêt communs – en encourageant, par exemple, de bons principes de télécommunications.

Mais je n’accepterais pas un accord comme celui de Novell, car je pense qu’il n’y a en fait aucun problème de propriété intellectuelle, et jusqu’à ce que Microsoft montre effectivement les brevets par lesquels il est concerné il n’y a pas lieu pour nous d’engager une action. Malheureusement pour Novell, je pense qu’ils ont conclu un accord qui leur donne un peu d’élan à court terme, pour un coût très élevé à long terme. L’avenir nous le dira.

14) Et que pensez-vous du standard OOXML et du Microsoft Open Promise ?

Je ne pense pas que la déclaration de l’ISO faisant de OOXML un standard apportera un quelconque bénéfice aux utilisateurs de Microsoft Office. Ils continueront d’utiliser un gros logiciel sans concurrence, qui ne respecte pas vraiment les standards. C’est dommage. Les clients de Microsoft ont eu l’opportunité d’initier une réelle innovation dans le monde du document, en encourageant Microsoft à prendre en charge le format ODF existant, ouvert et bien défini. Mais ils ne l’ont pas fait – Microsoft a réussi à pousser suffisamment de partenaires et de revendeurs dans le processus de standardisation, pour que la décision de l’ISO ne reflète rien d’autre que les intérêts commerciaux de Microsoft.

15) Nous disposons de GNU/Linux sur des portables ultra-mobiles à bas prix. Que pensez-vous de la révolution des Eee PC sous Linux ?

Je pense que c’est génial !

16) Acer, HP, MSI, Asus et bien d’autres veulent rejoindre le marché des UMPC sous Linux. Préparez-vous des accords pour porter Ubuntu sur certains de ces portables ?

De nombreuses personnes installent Ubuntu sur leurs UMPC, je pense donc qu’il est raisonnable que des fabricants puissent choisir de le pré-installer. La décision leur appartient ! Si vous pensez que ce c’est une bonne chose, alors cela vaut probablement la peine que vous les encouragiez à le faire.

17) Beaucoup d’analystes parlent d’une conquête du marché mobile par GNU/Linux dans les cinq ans à venir. Du smartphone à l’UMPC : le futur est Linux. Pouvez-vous parler de Ubuntu Mobile, de son concept, du présent et du futur ?

Oui ! Intel conduit un projet appelé Moblin, qui vise à produire une plate-forme pour le logiciel mobile destinée aux appareils portables, et sur laquelle nous basons Ubuntu Mobile. Les premières versions sont déjà sorties et la feuille de route est très excitante.

Il était généralement très coûteux de produire du logiciel pour des appareils électroniques grand public, car ils étaient tous construits sur du matériel spécialisé avec des systèmes d’exploitation et des environnements de développement d’application spécialisés. Nous avons pour objectif de changer cela – pour faire en sorte que vous puissiez faire un .deb pour x86 qui puisse être installé sur n’importe lequel de ces appareils électroniques grand public utilisant cette plate-forme. Cela permettrait de développer considérablement l’innovation dans le domaine du mobile.

18) Que pensez-vous de vos concurrents ? Fedora/Red Hat, openSUSE et Mandriva font du bon travail en plus de Ubuntu. Quelle distribution GNU/Linux préféreriez-vous si vous ne pouviez pas utiliser Ubuntu ?

Oui, toutes les distributions apportent leurs contributions à l’art et à l’industrie du logiciel libre. Je suis très heureux que de nombreuses sociétés continuent d’investir dans Linux, cela donne un écosystème plus sain et plus vivant qu’il ne le serait si une seule société le dominait. Je suis donc très content de cette concurrence. Si Ubuntu n’existait pas, j’utiliserais Debian.

19) Et quel est votre sentiment à propos de la dernière acquisition de Sun (MySQL) ? Travaillez-vous avec Sun pour porter OpenJDK sur Ubuntu ?

MySQL est une super société et une très bonne chose pour Sun. J’espère qu’ils sont heureux ensemble et que la société continuera de produire un superbe logiciel de gestion de base de données.

Oui, OpenJDK fait partie de la version 8.04 de Ubuntu (cependant ce n’est pas encore au coeur du système, et pas encore l’environnement Java par défaut). Nous espérons que la version 8.04 LTS sera certifiée TCK le moment venu. Et plus que tout, nous sommes reconnaissant envers les gens de Sun de nous avoir permis de conditionner OpenJDK sous la forme d’un paquet propre à Ubuntu, soigneusement intégré au reste du système d’exploitation. Nous voulons atteindre un résultat qui s’approche du “tout Java, tout Ubuntu” et j’encourage vos utilisateurs à l’essayer ! Assurez-vous que “universe” est bien activé sur votre machine Ubuntu, puis tapez “sudo apt-get install openjdk-6-jdk”.

20) Quels sont les prochains projets de Canonical ? Y-a-t’il des initiatives intéressantes en cours ?

Bien sur, mais ce n’est pas le bon endroit pour un communiqué de presse :-)

21) Enfin, pensez-vous que GNU/Linux soit “réellement” prêt pour le poste de travail ? De quelle façon pourrait-il être amélioré ?

Oui, je crois qu’il est prêt pour CERTAINS utilisateurs. Si vous voulez vraiment un poste de travail qui soit orienté vers le Web, alors Linux est un excellent choix, que ce soit avec Gnome ou KDE (Au fait, je suis vraiment impressionné par le travail effectué dans le cadre de KDE4). Nous savons qu’il y a des millions de personnes qui utilisent Linux aujourd’hui. Et nous nous focalisons sur la résolution des problèmes qui empêchent encore plus de personnes de l’adopter.

Je crois que le logiciel libre est intrinsèquement une meilleur manière de concevoir du logiciel. Mais nous ne devrions pas espérer être jugés sur notre moralité, nous devrions plutôt nous attendre à être jugés sur nos logiciels. Nous devons livrer quelque chose qui ait une meilleure APPARENCE et offre un meilleur CONFORT, alors nous pourrons espérer que les gens l’adopteront pleinement. Et une fois que les gens réaliseront qu’ils ont quelque chose de meilleur ET de durable ET porteur de plein de libertés, le monde sera alors un endroit fondamentalement différent. C’est notre but.

22) Notre entretien semble être terminé. Avez-vous quelque chose à ajouter pour nos lecteurs ? Merci pour votre temps et continuez cet excellent travail !

S’il vous plaît, participez ! Il y a de nombreuses manières de s’impliquer dans les projets en amont ou dans Ubuntu. Aidez à passer le mot, corrigez une bogue, ou traduisez quelque chose sur le poste de travail en italien !

Source : Interview with Linux-Magazine Italia

L’équipe OEM de Canonical a été approchée par plusieurs OEM qui souhaitent vendre des Netbooks (petits portables à bas prix conçus pour le Web) à base d’Ubuntu. Ils ont presque tous demandé les paquets standards et les mises à jours d’Ubuntu, avec un lanceur d’applications plus adapté aux nouveaux utilisateurs et qui ressemble plus à un “gadget” qu’à un PC.

Il existe des lanceurs très sympas – AWN est un de mes favoris actuel – mais les gens semblent préférer l’approche plus traditionnelle à 2 dimensions utilisant des onglets, ce qui fait que l’équipe OEM a implémenté pour ce type d’utilisation, un lanceur léger mais très classe. Le travail a été revu en détail dans Ars Technica et a été présenté dans Free Software Magazine et ailleurs.

Le but était de faire quelque chose de très simple qui puisse être testé facilement, fonctionne avec des périphériques tactiles et soit livrable très rapidement. Il fallait aussi qu’il soit efficace sur des machines peu puissantes, et marche bien sur du matériel Intel, qui semble être la plate-forme préférée de cette génération de machines et nous permet de glisser quelques nouveaux effets difficiles à obtenir sans le support matériel adéquat. Voici une copie d’écran d’une version récente :

Le nouveau lanceur est un logiciel libre – jusqu’à maintenant, tout ce que Canonical a financé, écrit et publié pour une utilisation publique sur Ubuntu l’a été sous licence GPL. Nous utilisons actuellement la licence GPLv3. Vous pouvez récupérer les paquets concernés sur un PPA public, ajoutez simplement la ligne suivante dans votre /etc/apt/sources.list :

deb http://ppa.launchpad.net/netbook-remic-team/ubuntu hardy main

Le PPA contient plusieurs paquets pour le lanceur, des applets pour GNOME, des outils de configuration du gestionnaire de fenêtre et des thèmes. Ces composants sont petits mais améliorent le confort d’utilisation d’Ubuntu fonctionnant avec le lanceur pour Netbook sur des écrans ayant une faible résolution verticale. Il y a aussi du code spécifique aux plates-formes matérielles Netbook d’Intel, n’installez pas ume-config-netbook à moins de disposer du bon matériel ! Voici tout le code produit par Canonical et publié sur Launchpad sous licences de logiciel libre :

https://launchpad.net/netbook-remix
https://launchpad.net/netbook-remix-launcher

Je suis particulièrement content des possibilités qu’il offre en libérant davantage d’espace sur l’écran pour la navigation Web, qui est probablement l’utilisation principale sur ce type de formats de machines :

Il y a encore plein de problèmes à résoudre, Ars a par exemple signalé des problèmes avec les palettes de GIMP, je vous invite donc à saisir l’opportunité de le tester avec les applications que vous pensez utiliser sur un petit portable (ou comme dirait El Reg, un portable). Et n’hésitez pas à faire un retour et proposer l’inclusion d’une branche ou deux si vous êtes prêt à faire un peu de bricolage !

Pour le reste, le remix Netbook utilise les paquets standards Ubuntu provenant de l’archive standard d’Ubuntu, avec les mises à jour de sécurité standards. Il respecte donc tous nos engagements habituels concernant la sécurité et la compatibilité. Vous pouvez recréer le remix Netbook en installant simplement la 8.04, en ajoutant le PPA à votre liste de dépôts, en allant chercher les paquets et en les configurant comme il faut pour votre système.

Le remix Netbook ne fait pas partie des “éditions officielles d’Ubuntu”, ce n’est pas comme Kubuntu ou Ubuntu ou Ubuntu Server. C’est un remix séparé, publié par l’équipe OEM de Canonical. Il sera probablement révisé en octobre lorsque la 8.10 sera livrée, mais cela dépend de l’équipe OEM de Canonical et de leurs clients, et ce n’est pas du ressort de l’équipe du projet Ubuntu.

En travaillant avec des constructeurs, l’équipe OEM créé des images d’installation personnalisées spécifiques aux matériels de ces OEM. Ils utilisent les paquets de logiciel libre que j’ai décrit, et ils peuvent aussi inclure des logiciels tiers choisis par les OEM que Canonical ne peut pas redistribuer, ce qui fait que nous ne pouvons pas publier les programmes d’installation personnalisés qui sont produits sous contrat. Ces images sont typiquement personnalisées à la main pour un démarrage plus rapide, ce qui signifie qu’elles ne fonctionnent que sur le matériel particulier auquel elles sont destinées, à l’instar de la version standard d’Ubuntu qui doit auto-détecter et se configurer pour n’importe quel matériel sur lequel elle est démarrée.

Nous avons vraiment voulu réaliser ce projet comme un remix d’Ubuntu – basé sur les paquets standards d’Ubuntu 8.04, avec une sélection de paquets modifiés et du code additionnel, mais en laissant les paquets constituant le coeur de la plate-forme inchangés. En termes de principes associés à la marque de fabrique d’un remix d’Ubuntu, les sociétés ne peuvent pas appeler leur plate-forme Ubuntu si elles ont modifié des paquets (en particulier les paquets du noyau et du bureau) mais elles le peuvent si elles ont juste ré-arrangé les paquets standards d’Ubuntu. Canonical est dans une position privilégiée en tant que propriétaire de la marque – nous pouvons certifier un noyau personnalisé si nous croyons qu’il a été fait d’une manière appropriée qui n’entrera pas en conflit avec les processus de maintenance standard d’Ubuntu, et si nous pouvons maintenir à jour le noyau personnalisé de la même manière que le noyau standard d’Ubuntu. Ce sont donc des machines certifiées Ubuntu par Canonical, même si elles sont plus personnalisées que ce que ne peuvent faire les autres dans le cadre des principes du remix.

Nous travaillons aussi avec deux sociétés qui veulent une innovation plus radicale au niveau de l’interface utilisateur. Canonical participe directement à la conception et l’implémentation de l’une des ces IHM, et nous sommes en train d’intégrer l’IHM de quelqu’un d’autre sur une base Ubuntu pour le second projet. Je n’ai vu aucune de ces IHM, pour des raisons de confidentialité, mais on m’a dit que les équipes qui travaillaient dessus pensent qu’elles ont des belles idées qui feront progresser, de différentes manières, l’état de l’art. Tout compte fait, cela va être passionnant de voir comment l’ère des Netbooks stimulera l’innovation dans l’utilisation de Linux, car il y a beaucoup de sociétés qui veulent construire des IHM différenciées sur une base standard de Linux. Et directement ou indirectement Canonical aidera au transfert de l’innovation vers KDE et GNOME et par conséquent à l’écosystème Linux tout entier.

Source : Netbooks pre-loaded with Ubuntu

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.

Source : Discussing free software synchronicity

Une évolution des projets à long terme concernant la gestion des versions d’Ubuntu. 8.04 LTS a représenté un très grand pas en avant dans notre réflexion sur la gestion des versions. Autant que je sache il n’y a jamais eu, à ce jour, de “plate-forme d’entreprise” livrée exactement selon le calendrier prévu, qu’il s’agisse d’un système d’exploitation propriétaire ou de Linux. En plus d’avoir prouvé que nous étions capable de produire une version LTS dans le délai standard de 6 mois, cela a montré que nous pouvions nous engager vis-à-vis d’une LTS dès le cycle précédent. Félicitations à ceux qui ont pris les décisions techniques, aux gestionnaires de versions, et à l’ensemble de la communauté qui s’est associée à nous dans ce but.

Le résultat est que nous pouvons promettre que la prochaine version LTS d’Ubuntu sera la 10.04 LTS, en avril 2010.

Ceci représente un bénéfice des plus extraordinaires, et pour moi assez inattendu, pour ceux qui déploient du logiciel libre. La plupart des gens supposent que la gestion précise des versions dépend du contrôle total des parties constituantes – et donc possible uniquement dans un contexte propriétaire. Microsoft écrit (presque) chaque ligne de code dans Windows, donc vous pourriez penser qu’ils devraient être capables de prévoir, et de respecter, une date de livraison précise. Mais dans les faits c’est l’inverse qui est vrai – les distributions de logiciels libres ou les vendeurs de systèmes d’exploitation libres peuvent fournir de meilleures garanties concernant les dates de livraisons que les vendeurs de systèmes d’exploitation propriétaires, car nous pouvons nous focaliser sur la tâche critique de la sélection des composants, l’intégration, le test, la gestion des correctifs et la distribution plutôt que sur des aspects que les projets en amont sont mieux à même de gérer – le développement de fonctionnalités pour les composants principaux. Ceci est pour moi une très bonne raison pour que les distributions se concentrent sur la distribution – c’est la seule chose qu’elles font et que les projets en amont ne font pas, d’où leur besoin d’investir énormément dans ce domaine afin d’être le meilleur support possible pour le travail réalisé en amont.

Nous nous sommes aussi engagés, pour la première fois, à publier régulièrement une série de versions intermédiaires pour la 8.04 LTS. Cela commencera trois mois après publication de la LTS, et sera répété tous les six mois jusqu’à ce que la LTS suivante soit sortie. Ces versions intermédiaires incluront la prise en charge de nouveaux matériels ainsi que l’ensemble des mises à jour publiées pour cette version. De cette manière l’installation d’une version intermédiaire fonctionnera sur de nouveaux matériels et ne nécessitera pas d’importants téléchargements de mises à jour.

Gerry Carr de Canonical a produit ce diagramme qui décrit très bien le planning de gestion des versions :

L’équipe d’Ubuntu a fait un travail extraordinaire en permettant que l’on puisse mettre à jour directement une version vers une autre version, ainsi qu’une LTS vers une autre LTS. Je suis très fier de faire partie de cette communauté ! Avec l’ajout des fonctionnalités pour la prise en charge de nouveaux matériels dans les versions d’une LTS, je pense que nous apportons une contribution à la communauté du logiciel libre – en favorisant la distribution de l’excellent travail de centaines d’autres équipes, de kernel.org à GNOME et KDE, d’une manière fiable et à un très large public.

Il y a une chose qui pourrait me convaincre de modifier la date de la prochaine LTS d’Ubuntu : l’opportunité de collaborer avec les autres grandes distributions en suivant un cycle coordonnée de versions majeures / mineures. Si deux sur trois parmi Red Hat (RHEL), Novell (SLES) et Debian étaient prêts à s’accorder à l’avance sur une date, et donc sur une combinaison de noyau, outils de compilation, versions de GNOME/KDE, X et OpenOffice, et acceptaient un cycle de six mois ainsi qu’un de 2-3 ans pour le long terme, alors je réalignerais avec joie les cycles à court et long terme d’Ubuntu sur ces bases. Je pense que les bénéfices de ce type d’alignement seraient énormes pour les utilisateurs, les projets en amont et les distributions elles-mêmes. Je développerai cette idée en temps voulu, pour l’heure disons que c’est juste mon rêve d’une vraie synchronicité du logiciel libre.

Source : The Art of Release

Sincères félicitations à la communauté Ubuntu toute entière pour le lancement réussi de 8.04 LTS. Ce fut notre meilleur cycle de production, depuis la planification à l’UDS-Boston l’année dernière, à laquelle nous avions plusieurs équipes et sociétés différentes, jusqu’à la phase de bêta-test qui fut passionnante autant du point de vue des méthodes de test que de la mise au point. Je pense que nous pouvons vraiment être fier de la qualité de 8.04 LTS. Du code à la documentation, des traductions à la promotion, cela a été un effort d’équipe avec l’objectif commun d’offrir au plus grand nombre la meilleur expérience possible du logiciel libre. Que Hardy puisse vivre longtemps et faire des heureux.

Je suis très conscient du fait qu’Ubuntu soit la partie visible de l’iceberg – nous sommes le fil conducteur, mais nous n’existons que grâce à l’extraordinaire dévotion et les efforts de milliers d’autres communautés et projets. Nous devons tous beaucoup à l’équipe qui a rendu possible le dépôt Debian “unstable”, et bien sur aux projets en amont que sont GNOME et KDE via le noyau Linux. Nous espérons que vous serez fiers de la manière dont nous avons mis votre excellent travail à la disposition des utilisateurs d’Ubuntu.

Donc, bravo tout le monde ! J’espère que les amis, la famille, les collègues et les autres auront la chance de pouvoir l’essayer et de comprendre pourquoi nous avons tant donné pour ce projet. Notre travail est vraiment très important – nous aidons le logiciel libre à s’élever à un nouveau niveau d’acceptation et d’adoption dans le monde entier. Le succès d’Ubuntu s’ajoute au succès du logiciel libre. Donc autant il peut être amusant, stimulant, l’opportunité d’une vie, une profession pour certains et une passion pour d’autres, autant il peut changer le monde. Je ne sais pas exactement quoi crier « Sauvez les pom-pom girls, Sauvez le Monde » mais pour moi vous êtes tous des Héros.

Mark

Source : The Heron takes flight

Windows est une plate-forme très importante et notre fierté légitime vis-à-vis de Linux et de l’offre GNU ne devrait pas nous faire perdre de vue l’importance qu’il y a à distribuer des logiciels qui soient utiles pour tous. Je crois qu’il faut proposer aux gens des logiciels libres d’une manière attractive et émancipatrice, et l’une des bonnes façons de le faire est de leur montrer des logiciels libres séduisants en les faisant fonctionner sur leur plate-forme habituelle, que ce soit Windows ou MacOS.

Firefox, est un exemple intéressant de réussite d’un logiciel libre, et je suis certain qu’une des clés de ce succès est son excellente intégration à l’environnement Windows. Une téléchargement rapide et une installation facile, cela fonctionne, tout simplement, après quoi les gens peuvent effectivement CONSTATER que le logiciel libre permet une navigation innovante et puissante qui est clairement meilleure que les alternatives propriétaires. J’ai remarqué que parmi les meilleurs projets libres nombreux sont ceux qui ont une histoire réussie sous Windows. MySQL et PostGres en ont une tous les deux. Bazaar marche bien aussi. Et les utilisateurs les apprécient – des utilisateurs qui peuvent alors avoir envie de faire un pas de plus pour s’installer complètement dans le monde GNU.

J’ai donc été absolument ravi en voyant de quelle manière Agostino Russo et Evan Dandrea ont développé le programme permettant d’installer Ubuntu 8.04 LTS sous Windows. Ce que j’y vois de vraiment très bien c’est la façon qu’il a d’utiliser le programme d’amorçage de Windows de manière pratique pour vous proposer l’option Ubuntu. Si j’étais un utilisateur de Windows qui soit attiré par Linux mais ne sachant pas comment l’aborder, ce serait réellement une bonne occasion d’y goûter, sans prendre de risque. Le fait de pouvoir installer et désinstaller un système Linux comme s’il s’agissait d’une application Windows est une grande innovation. Gloire à Agostino et Evan, et bien sur à ceux qui ont ouvert la voie à ce type d’approche (cela a été fait de plusieurs manières différentes). C’est clair, propre et professionnel :

Je suis un peu intimidé à l’idée que quelque chose d’aussi neuf que WUBI puisse être la première expérience que les gens auront de Linux, du logiciel libre et d’Ubuntu, mais les premiers retours sont positifs. La presse m’a posé une question qui commençait par “ça n’a pas marché pour moi mais … ” qui me rend un peu inquiet.

Donc – hier, je suggérais aux gens d’installer le Heron sur des serveurs, aujourd’hui, c’est un appel aux personnes qui ont une machine sous Windows et qui aimeraient voir fonctionner WUBI, à le tester et à informer les développeurs s’il y découvrent quelque chose à corriger à la dernière minute. Bonne chasse !

Source : Playing nicely with Windows

Les rapports de bêta-tests de la 8.04 LTS semblent globalement très positifs, ce qui est tout à l’honneur des équipes desktop et server qui ont travaillé très dur pour sortir ce génial Hardy Heron. J’ai utilisé Hardy sur mon portable pendant presque tout le cycle de développement, mais j’ai fait le grand saut à la maison du côté de mon pare-feu et de ma machine de bureau (Kubuntu) ce week-end.

La partie la plus agréable de la mise à jour du pare-feu est le fait que Michael a rendu l’outil de mise à jour de version indépendant de l’interface utilisateur graphique, ce qui fait que vous pouvez également l’utiliser pour les mises à jour de serveurs.

Donc, voici venu le grand moment de tester la mise à jour ! Soumettez vos bogues si vous rencontrez des problèmes avec votre configuration. Apparemment, cela fonctionne à la fois sur Ubuntu 6.06 LTS (Dapper) et sur Ubuntu 7.10 (Gutsy), donc les retours sur l’une ou l’autre des versions mises à jour seront les bienvenus.

sudo aptitude install update-manager-core

Cela vous assurera d’avoir installé l’outil de mise à jour de version. Maintenant vous pouvez démarrer le processus de mise à jour vers la version bêta actuelle :

sudo do-release-upgrade --devel-release

Ceci devrait récupérer la dernière version de l’outil de mise à jour, qui répertorie les différentes transitions entre les versions de librairies ce fait qu’il peut tenter de mettre à jour votre machine en douceur sans laisser traîner plein de paquets. Vous pouvez dire “non” si vous n’aimez pas le plan d’installation et de suppression proposé (dans ce cas, votre retour serait très utile !).

Pour les nouvelles installations, ce serait bien que la 8.04 LTS soit mise en place sur toutes les plates-formes serveur à haut-volume disponibles sur le marché d’aujourd’hui – si vous rencontrez des difficultés faites en part à l’équipe server. Ils espèrent atteindre le niveau du standard “Just Works” de l’équipe desktop, donc la barre est assez haute. De mon point de vue, la mise à jour fut sans problème – je salue et remercie tous ceux qui ont été impliqués.

Source : Hammering on the Heron

La tragédie qui se déroule au Kenya nous rappelle qu’une élection irrégulière place le “vainqueur” dans une situation pire que s’il avait perdu loyalement.

Celui qui sera Président à l’issu de cet affrontement de plus en plus malsain héritera d’une économie affaiblie, d’un parlement mécontent et divisé, et d’un peuple qui sait que l’on n’a pas tenu compte de ses souhaits. De plus il sera confronté à un risque accru d’attentat de la part de ceux qui considèrent que l’assassinat n’est pas un crime pire que la fraude électorale. C’est au mieux une victoire à la Pyrrhus. Il sera extrêmement difficile de faire quelque chose dans de telles conditions.

Il y a, cependant, des raisons à l’optimisme dans toute cette misère. Il semble que beaucoup de membres du parlement kényan qui furent dénoncé pour corruption pendant leurs précédents mandats aient été sommairement congédiés par leurs sections locales, en dépit des liens tribaux. Autrement dit, si vos administrés pensent que vous êtes un escroc, ils vous rejetteront même si vous êtes de leur ethnie.

Cela montre les débuts d’une responsabilité politique indépendante – cela montre que les citoyens qui votent au Kenya veulent des dirigeants qui ne soient pas teintés de corruption, même si cela signifie qu’il faut donner son vote à quelqu’un d’une tribu différente. Et c’est la clé du changement dont ont besoin les pays africains, pour faire émerger la démocratie. Les membres du parlement révoqués et les anciens présidents font l’objet d’enquêtes et de jugements, et aucun montant sur un compte en banque, provenant d’un butin mal acquis, ne vaut la honte d’un séjour dans une prison de votre successeur. Comme l’a appris Frederick Chiluba, il n’y a rien de tel qu’une retraite facile lorsque l’on vient d’une administration corrompue.

En fait, c’est comme si ceux qui ont des squelettes dans leurs placards essayaient de se cramponner encore plus au pouvoir, par peur des conséquences s’ils lâchaient prise. L’opinion de Robert Mugabe est sans nul doute qu’un moment amer au pouvoir est préférable à un moment amer après le pouvoir. Mais de plus en plus, ceux qui votent en Afrique découvrent qu’ils peuvent vraiment voter pour le changement. Et les pays limitrophes se rendent compte que certifier que des élections sont libres et loyales alors qu’elles sont loin de l’être, n’est pas bon pour leurs investissements et leurs profils économiques. Cela serait probablement beaucoup plus dur pour Robert Mugabe de rester au pouvoir illégalement s’il était *loin* d’avoir assez de votes pour y rester légalement. Vous pouvez truquer un peu une élection, mais il est très difficile de la truquer lorsque l’électorat tout entier vous abandonne, et quand personne ne vous accorde de la crédibilité.

Pour espérer une retraite heureuse un président actuel doit s’assurer que les institutions qui le (ou la) jugeront dans le futur sont indépendantes et compétentes, s’assurer qu’elles le resteront, et qu’elles garderont leurs mains propres. Cela prendra du temps, mais je pense que nous sommes sur le point de voir des changements salutaires dans les gouvernements devenir la norme et non une exception en Afrique.

Source : There is no victor of a flawed election

Nous avons assisté hier, à la plus extraordinaire faillite du commandement économique de ces dernières années, lorsque la Fed (Réserve fédérale des États-Unis) a appuyé sur le bouton “morphine” et à baissé ses taux de 0,75 %. Cela ne servira à rien.

Ce sont des moments extrêmement éprouvants et jusqu’à maintenant, la Fed dirigée par Bernanke n’a pas fait ses preuves. Les historiens pourraient bien attribuer la responsabilité de la détresse actuelle à Alan Greenspan, qui fut le premier a expérimenter l’utilisation de la morphine pour soulager de la douleur économique, mais le cas échéant ils devront également lui reconnaître une certaine modération dans sa prescription. Pendant que Greenspan occupait ses fonctions à la Fed, les grands économistes étaient convaincus que la solution à la détresse du marché était d’assurer au système financier l’accès à de l’argent facile.

Cela s’est montré efficace dans le court terme. Lorsque le LTCM (Long Term Capital Management) était prêt à exploser (les investissements privés, terriblement endettés, furent gérés par des théoriciens prix Nobel de finance qui parièrent sur quelque chose de sur qui ne donna pas vraiment le résultat escompté) Greenspan mis de l’ordre dans ses affaires. Lorsque la bulle Internet éclata, Greenspan préserva la vitalité du système financier en baissant les taux autant qu’il était possible de le faire, pendant une longue période, jusqu’à atteindre des seuils négatifs.

Un taux d’intérêt réel négatif signifie que nous sommes en fait rémunéré pour contracter des emprunts. Cela peut sembler bien, mais que ressentiriez-vous si j’utilisais les mots “payés pour prendre quelques doses de crack en plus” ? Le problème sous-jacent était que les gens s’étaient habitués à des taux de rémunérations élevés et ne voulaient pas accepter que les taux de rémunérations réels soient en train de baisser aux États-Unis. Ils s’étaient accoutumés à de l’argent facile et la politique de Greenspan assurait que l’argent restait disponible alors même que les gens ne savaient pas investir correctement cet argent facile.

Les taux bas incitent les gens à investir dans des actions, même si ces actions ne rapportent pas beaucoup. Cela entraîna rapidement une hausse du cours des actions et l’effet fut amplifié par des taux bas qui accentuaient les bénéfices des sociétés. Ce fut un soi-disant “atterrissage en douceur” – désastre évité. Greenspan connaissait forcément les risques, mais il lui a manqué le gros signal d’avertissement qui l’aurait probablement convaincu de revenir à des taux normaux : l’inflation. Les taux bas et en particulier les taux négatifs, ont historiquement mené à l’inflation. Greenspan a maintenu les taux bas parce qu’il n’y avait pas de signe d’inflation. On aurait dit que les États-Unis étaient entrés dans une nouvelle ère où la corrélation entre les taux et l’inflation n’existait plus. Les gens expliquaient ce phénomène en disant que les États-Unis avaient considérablement amélioré leur productivité (l’amélioration de la productivité est une sorte de médicament anti-inflation). Maintenant, avec du recul, il s’avère que la vraie raison de l’absence d’inflation était que les chinois avaient énormément amélioré leur productivité et que les consommateurs américains dépensaient beaucoup en achetant des marchandises chinoises ce qui fait que c’est la croissance de la productivité chinoise, non pas la croissance de la productivité américaine, qui maintenait les prix américains bas.

Lorsque les choses se calmèrent et alors que les gens auraient dû profiter de la pause pour assainir leurs affaires, Greenspan leur à permis de se mettre facilement dans une situation encore pire. L’argent facile avait rendu les prix du marché des actions artificiellement hauts, de sorte que les investisseurs se sentaient riches. Pire, l’argent facile avait fait monter artificiellement le prix de l’immobilier (d’environ 45 %), au point que tout le monde se sentait plus riche qu’il ne l’avait prévu ou espéré.

Pour dégrader encore plus la situation, une série d’innovations financières engendra toute une industrie conçue pour aider les gens à se ré-endetter pour leurs maisons. Je me rappelle avoir essayé de regarder la TV aux États-Unis et j’avais été stupéfait par le nombre de publicités pour les “prêts hypothécaires”. Ils donnaient l’impression que la mutation de votre principal actif – l’achat de votre maison – en GAB était une bonne chose. En fait, c’était un moyen de dépenser toute votre richesse. Et avec l’inflation sur le prix de l’immobilier, c’était une façon de dépenser de l’argent que vous n’aviez pas vraiement. Un moyen pratique de plonger votre famille dans un profond et sombre endettement. Le résultat ? L’américain moyen possède moins sa maison qu’il y a 30 ans – 55 % contre 68 %. L’argent facile appauvrit les gens. La société avec les publicités les plus énervantes, Ditech (et je suis confus de contribuer à la notoriété de leur site Web en les citant, peut-être serait-t-il préférable de faire un lien vers leur service client) à un slogan “Les gens sont malins” et un modèle commercial “Les gens sont stupides”. Leurs produits les “plus populaires” me donnent l’impression d’être conçus pour faciliter la transformation de la valeur nette d’une propriété – un bien – en une nouvelle dette.

Pourquoi est-ce Greenspan a fait ça ? Je pense qu’il a sincèrement cru qu’il y avait quelque chose de différent dans le monde moderne qui avait altéré les lois de la gravité économique. J’imagine qu’il ne voit plus les choses ainsi.

Mais Greenspan n’est plus Directeur de la Fed. Hier, Ben Bernanke à vacillé et dans son vacillement nous avons eu la mesure de l’homme.

Greenspan agissait avec attention, de manière logique et dans l’ensemble prudement. Plusieurs années de données économiques irrégulières sont une indication pouvant faire penser que les règles ont changé. Vous aurez à adopter une approche suisse (700 ans de stabilité) ou chinoise (”nous pensons qu’il est trop tôt pour dire si la Révolution Française fut une bonne idée”) pour vous en tenir à des théories économiques qui sont depuis longtemps en contradiction avec les faits. Greenspan a fait une erreur et elle aura des conséquences énormes pour les États-Unis pendant une génération, mais il y avait des raisons pour expliquer son erreur. Bernanke vient juste de vaciller, il a paniqué, malgré qu’il en sache plus.

Nous avons maintenant une explication rigoureuse de tout ce qui s’est passé. Nous avons fini par comprendre, assez clairement, ce qui ce passe dans le monde. Le vent déflationniste venant de l’Est a été identifié. Nous savons qu’il n’y a pas de miracle de la productivité aux États-Unis, pas de changement dans les lois de la physique ou de l’économie. Nous savons donc que les patients américains sont dépendants à la morphine que procure l’argent facile, traitement qui fut prescrit par le Dr Greenspan avec de bonnes intentions, traitement qui pendant les 7 dernières années a rendu les patients plus malades qu’ils ne l’étaient. De nos jours, l’utilisation de la morphine est une mauvaise pratique; pas une innovation économique. Nous connaissons les conséquences de la morphine – le prix des actions augmente artificiellement (4 % hier, à l’annonce de la piqûre), le prix de l’immobilier fera un bond, les sociétés ne tarderont pas à avoir des difficultés pour rembourser leurs emprunts.

Bernanke pouvait espérer faire ce que Greenspan à fait – se retirer avant que la dépendance ne s’avère totalement flagrante. Trop tard. Alors que la Fed n’a clairement pas envie de l’admettre, les marchés viennent de donner leur point de vue, que le pronostic n’est pas bon. Ils sont assez intelligents pour se rendre compte que tout ce qu’à pu faire Bernanke est de dissimuler les symptômes d’un malaise et nombreux sont ceux qui utilisent l’acalmie passagère pour gagner des lieux plus surs. Je m’attends à ce que le soulagement soit bref, le redressement du marché s’estompera, la déroute a été ajournée mais pas évitée.

J’ai commencé en décrivant l’action de la Fed comme une faillite du commandement économique. Certaines personnes sont assez chanceuses pour pouvoir diriger dans le creux de la vague – ils prennent le pouvoir quand les choses sont en mauvais état et ne peuvent qu’aller mieux. Ils ont pour ainsi dire, l’air de héros même si leur magie n’utilise pas de gris-gris. D’autres ont moins de chance, ils ont la garde d’un bien qui est à son apogée. Dans le cas de Bernanke, il est dans la seconde catégorie. Il doit être capable de parler clairement et franchement de la tâche difficile qu’il faut accomplir aux États-Unis. Il doit faire appel au meilleur du potentiel américain – un enthousiasme à travailler dur, être malin et accepter les conséquences d’un refus de se comporter ainsi. Il doit diriger dans les pires circonstances. Mais c’est le lot du commandement.

Heureusement pour Bernanke, il y a un consensus vis-à-vis de l’indépendance de la banque centrale qui est reconnue comme étant la seule approche crédible pour la conduite de l’économie. En cas de besoin, cette indépendance donne à Bernanke le droit de ne pas être d’accord avec les dirigeants politiques. Compte-tenu des récentes annonces faites par la Maison Blanche – plus de morphine, plus d’endettement pour les pays du monde les plus endettés – il apparaît que l’administration Bush n’a pas la volonté de mettre en place un vrai programme de réhabilitation. Bernanke devra diriger sans soutient politique, ce qui rendra la tâche très difficile. Nos plus grands et plus célèbres dirigeants sont ceux qui ont gouverné en des temps difficiles. C’est également vrai dans le cas des échecs des gouvernements. Apaisement, ou réhabilitation. Chamberlain, ou Chruchill. Jusqu’ici, ce fût Chamberlain.

Source : Economic oversteering

Est-il possible d’avoir des supports de formation développés en partenariat avec la communauté, disponibles sous licence CC, ET accessibles via des centres de formation ? C’est ce que nous essayons de voir chez Canonical avec notre cours sur Ubuntu.

Chez Canonical, le travail de Billy Cina a permis de progresser vers l’objectif d’avoir un catalogue complet de formations possibles à destination des utilisateurs commerciaux d’Ubuntu. Les sociétés qui veulent s’assurer que leurs équipes sont formées rigoureusement, et les personnes qu’ils veulent faire valoir leurs compétences sur Ubuntu, ont besoin d’avoir un référentiel certifié et reconnu pour valider les connaissances.

La plus grande partie du travail qui est fait dans ce sens suit le modèle traditionnel, dans lequel le contenu est financé comme un investissement privé, pour être ensuite proposé sous licence à des centres de formation agréés qui vendent les cours à leur clientèle locale. Ces cours sont généralement vendus à des sociétés qui ont adopté une plate-forme ou un logiciel et veulent garantir un niveau de connaissances cohérent au sein de l’entreprise. De nombreuses sociétés migrent à la fois les postes de travail et les serveurs vers Ubuntu, ce qui fait que la demande de compétence est croissante. Nous avons un cours pour les fabricants de systèmes et un cours pour les administrateurs système qui sont disponibles auprès de centres de formation agréés.

Mais nous avons aussi voulu essayer une approche différente, qui pourrait être plus accessible à la communauté Ubuntu et qui pourrait permettre de concevoir des supports d’une qualité encore supérieure. Nous pensons que les ingrédients clés sont les suivants :

• Utilisation d’un format ouvert (Docbook)
• Document source disponible à partir d’un dépôt Bazaar public (ici)
• Licence ouverte (CC-BY-NC-SA)
• Travail avec l’équipe de documentation d’Ubuntu, qui a une très grande expérience

La licence est copyleft et non-commerciale, de sorte qu’elle est utilisable par toute personne pour sa propre éducation et son instruction avec la nécessité qu’une utilisation commerciale induise en retour une contribution au projet.

C’est déjà un livre de 400 pages qui donne une bonne vision de l’utilisation du poste de travail sous Ubuntu, une ressource très utile pour les gens qui débutent sur Linux et Ubuntu.

Nous arrivons à un stade où nous pouvons publier un “PDF quotidien” qui est compilé pendant la nuit à partir de la toute dernière version (”trunk”). Ainsi tout le monde a un accès libre à la toute dernière version et bien sûr chacun peut créer une branche bzr à partir du document pour y faire les modifications qui lui conviennent.

Si vous voulez voir la dernière version, essayez ceci :

• installez Bluefish (utile en tant qu’éditeur docbook)
• vérifiez que vous avez bzr 1.0
• vérifiez que Launchpad a une clé SSH pour vous

Saisissez :

bzr launchpad-login votre-nom-d-utilisateur-launchpad
bzr branch lp:ubuntu-desktop-course


La source est énorme (712 Mo, beaucoup d’images dans un gros livre), alors prenez une tasse de thé, et lorsque vous reviendrez vous aurez la dernière version, toute chaude et bien infusée :-) Cela vous fera une grande quantité de supports si vous donnez des formations informelles. Les corrections et les ajouts seront plus que bienvenus, publiez simplement votre branche dans Launchpad et demandez une fusion de vos modifications.

Source : A community approach to commercial training materials

O’Reilly, organisateur de Ubuntu Live, vient juste de publier l’appel à contributions pour Ubuntu Live 2008. Le thème de l’évènement est “L’amener plus loin“, ce qui je pense est parfait pour Ubuntu cette année !

Le sous-titre de la conférence devrait probablement être “Passer en phase de production”, car il semblerait que partout où je regarde ces temps ci les gens soient en train de mettre Ubuntu en production. Peut-être est-ce la préparation de la version LTS d’avril, peut-être est-ce juste que la confiance en Ubuntu pour des déploiements sur le poste de travail et le serveur a atteint un seuil décisif, mais quelle qu’en soit la raison je suis ravi de l’adoption grandissante de la plate-forme que notre communauté livre avec une précision de métronome.

Ubuntu Live 2008 promet donc d’être instructive, à l’heure où nous commençons à récolter les bénéfices de cette expérience. Si vous avez des déploiements ou des sujets intéressants que vous aimeriez partager, UL2008 pourrait être le bon endroit pour le faire ! Je suis particulièrement intéressé par les conférences qui décrivent :

• les déploiements d’Ubuntu sur le poste de travail à l’échelle gouvernementale (il y en a déjà plusieurs)
• les déploiements spécifiques, par exemple des clusters à haute performance, ou des solutions verticales
• les déploiements systèmes de virtualisation où Ubuntu est la plate-forme hôte ou hébergée
• les déploiements hors-normes de fermes de serveurs pour l’hébergement ou le Web
• les machines basées sur Ubuntu

Vous pouvez soumettre une proposition directement ou en lire d’avantage à propos de la conférence. J’espère vous y voir !

Source : Ubuntu Live – Call for Papers

J’ai complètement oublié de parler de la version 1.0 de Bzr l’année dernière, mais c’était une excellente mouture et au dire de tous, très bien reçue. Félicitations à la communauté Bazaar pour leur dynamisme ! Je crois que la version 1.1 est maintenant stabilisée, et c’est génial de voir qu’ils vont continuer à sortir régulièrement de nouvelles versions.

J’ai récemment observé une augmentation du nombre de contributeurs à Bazaar, ce qui a généré de nombreuses branches, petites mais utiles, proposant des correctifs à divers bogues complexes, des systèmes d’exploitation et des intégrations à d’autres outils. Un des projets les plus intéressants qui suscite beaucoup d’attention est BzrEclipse, intégrant Bzr de manière naturelle dans l’environnement de développement logiciel Eclipse.

Je pense que les projets open source évoluent à partir d’une phase initiale pendant laquelle ils s’accordent mieux avec un petit groupe soudé de contributeurs qui pose les bases, pour arriver à un point où l’outil ou l’application est utilisable par une plus large audience. Ensuite, ils doivent passer d’un état “bien contrôlé” à une situation ouverte aux contributions de personnes qui souhaitent juste corriger un petit bogue ou ajouter un petite fonctionnalité. C’est une transition assez difficile, car les compétences sociales requisent pour faire avancer le projet sont assez différentes dans les deux cas. Il s’agit non seulement d’être doué pour la communication, mais il faut aussi avoir de bons outils pour gérer la base de code qui reçoit un flot des nouvelles petites contributions provenant de nouveaux contributeurs n’ayant pas fait leurs preuves.

Il semble que l’une des “bonnes pratiques” clé qui ait émergée est l’idée des architectures à greffons, qui permettent à de nouveaux développeurs d’apporter une extension, un greffon ou un complément au code de base sans avoir à apprendre trop de choses sur le fonctionnement interne du projet, ou avoir à participer à de trop nombreux processus lourds. J’aimerais généraliser cela et dire qu’une bonne conception, avec des couches clairement définies et pragmatiques, permet à de nouveaux contributeurs de faire rapidement des contributions utiles au code de base, car les couches offrent des abstractions utiles en amont.

La décision de prendre en charge les compléments mutli plate-forme a vraiment été bénéfique pour Firefox. Je suis ravi d’entendre qu’OpenOffice va dans la même direction.

Bazaar est très bien architecturé. Il dispose non seulement d’un système de greffon bien conçu, mais il a aussi une architecture en couches très utile et pragmatique qui réserve les aspects intrinsèques complexes à ceux qui ont réellement besoin de les connaître. J’ai observé comment différentes équipes de contributeurs, ou des individus, ont introduits des formats on-disk complètement nouveaux avec des nouvelles caractéristiques de performance, de manière complètement orthogonale au reste du code. Donc si vous êtes intéressé par la performance de status et de diff, vous pouvez travailler sur l’implémentation d’un arbre d’états sans avoir à vous soucier du stockage de version à long terme ou des comparaisons d’historique de branche.

L’architecture en couches peut aussi poser des problèmes, lorsque les couches sont définies trop tôt et qu’elles ne reflètent pas la réalité pragmatique du code. Par exemple, on peut citer “l’échange de points de vues” entre les gens de chez ZFS et la communauté travaillant sur le système de fichiers de Linux, qui ont des opinions très différentes sur l’importance et les bénéfices de l’architecture en couches.

Quoi qu’il en soit, bravo aux gars de Bazaar pour l’imminente version 1.1 et pour l’adoption d’une architecture qui facilite l’implication des contributeurs.

Source : Good architectural layering, and Bzr 1.1

Je suis absolument ravi de voir ce graphique des bogues en attente dans Inkscape depuis que le projet à migré sur Launchpad.

Comme vous pouvez le voir, la communauté Inkscape s’est bien occupée de l’affectation et de la correction des bogues, réduisant de manière significative le nombre de bogues “nouveaux et inconnus” et donnant aux développeurs, une idée plus précise de l’endroit où se situent les bogues à traiter.

Une grande partie de mon intérêt personnel pour le logiciel libre est motivé par l’idée que nous pouvons être plus efficace si nous collaborons mieux. Si nous voulons que le logiciel libre soit la norme pour l’informatique personnelle, alors nous devons montrer, entre autres choses, que l’approche ouverte du logiciel libre utilise une ressource globale de talents, d’une manière assainie et plus dynamique que ne le fait l’ancienne approche propriétaire pour produire des logiciels. Nous n’avons pas l’argent de notre côté, mais nous avons la puissance de la collaboration.

J’investis personnellement beaucoup dans Launchpad parce que j’aime l’idée qu’il puisse aider à tracer la voie d’une meilleure collaboration dans l’ensemble de l’écosystème du développement de logiciel libre. Je recense les méthodes suivies par les projets qui fonctionnent le mieux et j’encourage les gars de Launchpad à les démocratiser. Ces améliorations et potentialités aideront chaque projet individuellement, mais cela aidera également chaque distribution Linux. Ce type de graphique me donne le sentiment d’une vrai réalisation dans ce sens.

Bryce Harrington, qui travaille quelquefois pour Canonical et qui est membre de l’équipe Inkscape, m’en a parlé et à décrit cette expérience. J’ai interrogé quelques personnes chez Inkscape et ils semblent sincèrement très heureux du résultat. Je suis ravi. Merci !

Source : A fantastic result for Inkscape with Launchpad