PiTiVi vise une certaine simplicité d’utilisation et se targue d’offrir une bonne intégration au bureau, notamment en suivant les directives GNOME sur l’interface utilisateur. Il annoncent d’ailleurs, non sans humour, sur la page d’accueil du site officiel :

We have some highly trained designer monkeys that work towards that goal, and can even recite the GNOME Human Interface Guidelines in their sleep, backwards, all for you.

que l’on pourrait traduire par

Nous avons des petits singes surentrainés qui travaillent dans ce but [d'efficacité et d'intuitivité], et qui peuvent même réciter les directives GNOME sur l’interface utilisateur pendant leur sommeil, à l’envers, le tout rien que pour vous.

Écrit en python, PiTiVi se base sur le framework vidéo/audio Gstreamer, ce qui lui donne accès à une multitude de formats. Les fonctionnalités incluent la possibilité de gérer un nombre illimité de calques audio et vidéo, de pouvoir annuler toutes les modifications effectuées, ainsi que toutes les actions classiques de manipulation d’images dans une vidéo, ou des outils de manipulation audio, entre autres.

En plus de suivre à la lettre les GNOME Human Interface Guidelines (directives GNOME sur l’interface utilisateur), PiTiVi utilise la bibliothèque GTK pour la gestion de son interface utilisateur, ce qui lui offre une intégration parfaite avec le système de thème GTK ainsi que plus globalement l’environnement de bureau GNOME.

Du point de vue de son développement, PiTiVi profite de l’infrastructure offerte par le projet GNOME. Il est traduit par les équipes de traduction GNOME, ce qui lui assure une bonne qualité ainsi qu’une bonne couverture des langues.

À lire pour en savoir plus sur le sujet : le point sur PiTiVi en février dernier (en anglais), par Jono Bacon, community manager chez Ubuntu, employé par Canonical.

VLMC se base sur les fondements de VLC (libvlc) et à l’heure actuelle nécessite au moins la version 1.1 de la bibliothèque (version encore en développement). Le logiciel permettra donc d’éditer tous les formats de vidéo supportés par son grand frère VLC et devrait fonctionner au moins sous Windows et Linux. Les développeurs ont pour ambition d’en faire un réel logiciel de montage vidéo, et donc de ne pas se limiter à des fonctionnalités de ripping ou de découpage, comme d’autres logiciels savent déjà le faire.

Le Google Summer of Code 2010 (programme permettant à des étudiants de travailler pendant tout un été sur un projet de logiciel libre tout en étant rémunéré par Google) a accepté le projet VideoLAN pour la session 2010, ce qui devrait permettre de donner un coup d’accélérateur au développement de VLMC.

À suivre donc, puisque le logiciel est encore en plein développement, il n’est pour le moment pas possible de le tester facilement et de le juger vis-à-vis de ses concurrents déjà en place.

Fully Automatic Installation est un outil développé par Thomas Lange, développeur Debian, depuis plus de 10 ans. Cet outil principalement basé sur des scripts shell et Perl permet l’installation entièrement automatique des postes sous Debian GNU/Linux, donc sans que le processus ne requiert d’intervention humaine.

Il est capable d’installer un cluster de machines, une infrastructure de serveurs, ou bien encore un parc de postes de travail. Il supporte de multiples distributions, mais reste un choix de prédilection pour Debian (puisque son auteur en est un développeur) et ses dérivées comme Ubuntu (même si l’intégration au sein des dépôts Ubuntu n’est pour le moment pas effective).

Les possibilités de configuration de l’installation sont assez vastes : de la configuration des partitions à la liste des paquets installés en passant par l’exécution de scripts shell, tout (ou presque) le processus est personnalisable. La notion de classes permet à l’administrateur de définir des scénarii d’installation modulaires, et donc plus ou moins différents, chaque machine pouvant ainsi bénéficier d’une installation lui correspondant complètement, bien que automatique.

FAI nécessite pour fonctionner un serveur DHCP, un serveur TFTP, et un serveur NFS. Ce dernier sert le config space, qui contient tous les paramètres définis par l’administrateur, ainsi que le nfsroot, qui contient le système de fichiers racine utilisé pour effectuer l’installation.

Récemment, Thomas Lange a donné une interview à InfoQ : http://www.infoq.com/news/2010/03/fai

NEPOMUK

Caché derrière l’acronyme barbare de NEPOMUK, se cache le concept (non-moins “obfusqué”) d’ontologie. Dans le domaine informatique, l’ontologie touche aux méta-données, ces informations qui ne sont pas stockées dans les fichiers de l’utilisateur mais qui sont plutôt des données descriptives des fichiers ainsi qu’aux liens que l’on peut déduire de ces informations. Ces méta-données qui intéressent NEPOMUK sont par exemple les tags des fichiers MP3 : ce n’est pas la donnée primaire du fichier MP3 mais des caractéristiques additionnelles stockées dans le fichier.

Les développeurs du projet NEPOMUK divisent ces informations en 3 catégories :
- données du bureau (comme les tags des MP3, droits sur les fichiers, timestamps, …)
- informations rajoutées par l’utilisateur (nom de l’auteur d’un document OpenOffice, annotations sur un email, …)
- les données qui ne figurent pas dans les deux catégories précédentes (et qui sont beaucoup plus difficile à récupérer : emplacement depuis lequel un fichier a été téléchargé, pièces-jointes des emails qui peuvent perdre leur information de lien avec l’email lors de leur sauvegarde sur le disque dur)

Le but de NEPOMUK est ainsi de proposer des outils pour créer, gérer et requêter sur ces données et ainsi de pouvoir exploiter cette somme d’information dont on ne soupçonne pas toujours la présence.

Au démarrage de KDE 4 on ne peut passer à côté de ce démon qui semblait utiliser beaucoup de ressources pour indexer les fichiers dans les premières heures de KDE 4. Cette gestion semble avoir été revue et il suffit de s’armer de patience lors d’un premier démarrage de l’environnement e bureau pour pouvoir utiliser l’outil. KRunner (un lanceur d’application de KDE que l’on peut appeler via le raccourci Alt+F2) propose par exemple un plugin pour NEPOMUK qui permet ainsi d’accéder à la liste des fichiers du répertoire home de l’utilisateur. “Alt+F2″, “archli” et voilà tous les fichiers indexés correspondants au thème “ArchLinux” recherché.

Derrière le terme barbare d’ontologie se cache pour le domaine de l’environnement de bureau une mine d’information encore non exploitée que l’on atteint enfin avec NEPOMUK. L’avenir nous dira si l’exploitation de ces informations se révèlera pertinente pour l’utilisateur. Pour cela les développeurs d’applications “de bureau” ont maintenant des outils : charge à eux de les exploiter.

Pour résumer, Chromium est la version libre à l’origine de Google Chrome. Un article publié sur le blog de Chromium fait un point sur les différences entre les deux navigateurs. Chrome est basé sur Chromium et est essentiellement un rebranding aux couleurs de Google. La firme ajoute également un système de mise à jour (GoogleUpdate) et RLZ. RLZ permet à Google de récupérer certaines informations à usage statistique lorsque l’utilisateur utilise le moteur de recherche, comme le site utilisé pour télécharger Google Chrome. Et c’est là que le bât peut blesser… Plusieurs fonctionnalités présentes dans les deux logiciels peuvent également être sujets à des inquiétudes sur le respect de la vie privée. Chrome et Chromium activent par défaut certaines options qui communiquent avec Google, par exemple les suggestions automatiques lors de l’utilisation de la barre d’adresse. Il faut donc veiller au paramétrage qui convient le mieux pour allier fonctionnalité et respect de la vie privée.

En terme de fonctionnalités, Google Chrome a apporté une innovation lors de sa sortie : la gestion des onglets dans des processus séparés. Cela évite de crasher tout le navigateur par la faute d’un seul onglet, et la présence d’un gestionnaire de tâches interne au navigateur permet à l’utilisateur de tuer les processus problématiques. Toujours dans le but d’améliorer l’expérience utilisateur, on trouve une page d’accueil dynamique, générée en fonction de l’historique des sites visités. Sous le capot, on trouve le moteur de rendu HTML Webkit, et un moteur Javascript aux performances améliorées.

Un nouveau navigateur, surtout venant d’une énorme entité comme Google ayant une puissance marketing rare, ne peut qu’avoir des effets positifs sur l’état du web en général. Il faut se souvenir qu’il y a encore quelques années, Internet Explorer dominait de façon quasi-monopolistique le marché des navigateurs et par là même empêchait le développement des standards du web ainsi que de beaucoup d’innovations (certaines qui constituent ce que l’on appelle parfois le Web 2.0). L’arrivée puis l’expansion de Firefox a joué un rôle prédominant dans le processus de standardisation et modernisation du web, mais l’appui de Google avec son navigateur comme nouveau concurrent est le bienvenu.

La plupart des distributions se basent sur un ensemble de paquets (contenant logiciels, bibliothèques, et autres) liés entre eux par différents types de dépendances. Les formats de paquets les plus répandus sont les fichiers deb (Debian et dérivées), et rpm (RedHat et dérivées). Les outils dpkg et rpm permettent de manipuler les paquets en local. La couche du dessus, qui contient des outils comme apt et rpm, permet la résolution des dépendances. L’utilisateur peut donc choisir les paquets qu’il souhaite installer, et les dépendances sont résolues afin que les paquets nécessaires soient installés et que les éventuels paquets en conflit soient supprimés. L’outil de résolution des dépendances a pour seul but de répondre aux besoins de l’utilisateur sans enfreindre les règles de dépendances et de conflits définies. Éventuellement, cet outil peut répondre qu’il n’existe aucune solution au problème posé…

Dans les faits, il existe différents solveurs de dépendances différents entre les distributions, et même au sein de chaque distribution. Dans la plupart cas, il n’existe pas de bonne raison à cet état de fait. Seuls certains domaines spécifiques (par exemple, l’embarqué) peuvent nécessiter un algorithme de résolution différent. Lors de sa conférence intitulée “Cross-distro dependency resolution: reusing solvers among distros“, Stefano Zacchiroli, développeur Debian, présente le travail réalisé dans le but de créer un format standard de description des problèmes de résolution de dépendances. Ceci a pour but de pouvoir abstraire ces derniers en omettant les spécificités de chaque distribution (par exemple, transformer les différents niveaux de liens entre les paquets dans Debian : Depends/Recommends/Suggests/Conflicts/Replaces/etc. et la notion de paquets virtuels), et donc de pouvoir travailler sur des solveurs performants et éventuellement utilisés largement par les différentes distributions, en évitant la duplication du travail.

Cette abstraction correspond au format CUDF, acronyme de Common Upgradability Description Format. Un fichier CUDF est un simple fichier texte basé sur la RFC 2822, listant des paquets (chacun ayant un certain nombre de propriétés), le tout organisé en 3 sections :

• l’univers des paquets, c’est-à-dire la liste des paquets disponibles dans les dépôts
• les paquets installés
• la requête de l’utilisateur

Un document contenant les spécifications complètes est disponible, mais pour commencer il est suffisant de lire CUDF Primer. Ce format est implémenté dans la libCUDF, également disponible sur le site du projet CUDF. Il existe un format spécifique pour Debian, Debian CUDF, qui abstrait moins de chose que le format CUDF, et qui trouve son utilité dans le travail d’uniformisation des solveurs au sein de la distribution Debian.

Enfin, l’équipe derrière CUDF souhaite collecter des données auprès des utilisateurs de systèmes de paquets afin de constituer une base de cas d’utilisation réels sur les problèmes de résolution de dépendances. De plus, une compétition sera organisée entre les différents algorithmes de résolution proposés.

Tout ce travail, même s’il peut sembler actuellement abstrait, pourrait permettre à terme d’améliorer les systèmes de paquets dans les distributions Linux.

Kohei Yoshida signale qu’il a réussi le tour de force de  de ne pas dégrader l’utilisation de Calc dans la plupart des cas, mais ce n’est pas l’avis de deux des développeurs employés par Oracle… Ils estiment qu’il n’est pas encore temps d’intégrer cette modification, ils ont noté que le calcul en chaine des cellules contenant des formules n’est pas assez optimisé pour tenir la charge. Ils ont également constaté que l’affichage des objets graphiques ou des notes est décalé. C’est un problème déjà connu sur la version actuelle, mais l’augmentation de la limite montre ce problème de façon trop flagrante.

Il est clair que ce type de limitations seront dépassées prochainement dans la suite bureautique libre. En attendant, Kohei Yoshida a décidé de d’intégrer ses  modifications dans la version stable de Go-00 en version 3.2. Il est donc possible depuis une Ubuntu Lucid Lynx ou dans la prochaine version d’openSuse d’utiliser un tableau affranchie de la limite de 65536 lignes.

Sous le capot, le changement majeure concerne la bibliothèque boite à outils pour l’affichage sous KDE, le toolkit Qt, qui sera intégré en version 4.6.

Pour l’utilisateur, on peut noter la possibilité de regrouper plusieurs fenêtres (y compris des fenêtres d’applications différentes) dans une unique fenêtre avec des onglets. Fini donc les problèmes posés par les applications n’implémentant pas le support des onglets, ou encore le casse-tête causé par les raccourcis claviers incohérents entre les différentes applications : c’est le gestionnaire de fenêtre lui même qui gère la notion d’onglet.

La liste des objectifs pour cette nouvelle version est disponible, tout comme l’état d’avancement des nouvelles fonctionnalités prévues.

Pour Aaron, 2009 a été une année riche de nouvelles versions de KDE. Après la sortie de KDE 4.0 début 2008, 2009 a vu arriver KDE 4.2, première version recommandée pour le grand public, puis KDE 4.3. Afin de mener à bien tout le travail de release management, le projet KDE est passé d’un système basé sur un unique release manager à un travail d’équipe de la release team, composée de tous les “corps de métiers” existant dans l’écosystème KDE, c’est-à-dire non seulement des développeurs, mais aussi des personnes en charge de l’internationalisation par exemple.
Du côté des logiciels eux mêmes, les sorties des versions 2 de Amarok, lecteur musical killer app de KDE, et Koffice, la suite bureautique, sont notées comme des succès importants de cette année 2009. D’autres applications KDE ont évolué afin d’utiliser pleinement les possibilités de la plateforme KDE 4 : on peut citer KDevelop (IDE), Digikam (gestion de photos), K3B (gravure) ou encore Konversation (client IRC).
2009 a également vu des avancées en ce qui concerne l’utilisation de KDE sur des plateformes autres que Linux et Unix, notamment Windows et Mac OS.
D’un point de vue plus technique, KDE a évolué vers encore plus d’utilisation de bibliothèques standards et partagées d’abord au sein des applications KDE, mais plus largement lorsque cela est possible par les différents environnements de bureau existant.
Du côté de l’usabilité et de l’expérience utilisateur, Aaron se félicite de l’abandon de l’historique système de barre des tâches (system tray) au profit de l’interface plus innovante de KDE 4.

La rencontre annuelle de la communauté KDE, Akademy, est considérée comme un important succès de l’année 2009, puisqu’elle a été organisée conjointement avec le GUADEC, l’événement équivalent pour GNOME. Cette rencontre des deux communautés a certainement eu des effets positifs pour les deux projets et plus généralement pour le bureau Linux.

Aaron Seigo a écrit à la suite de cette rétrospective une série de billets concernant KDE en 2010, facilement trouvables sur son blog.

Sur la partie poste de travail, on trouvera GNOME 2.30, qui sortira en mars, et qui sera la dernière version de la branche 2.X, avant GNOME 3.0. Côté navigateur, Firefox devrait évoluer en version 3.6, alors que pour la messagerie Thunderbird sera disponible dans sa nouvelle version 3.0, en plus de la possibilité d’utiliser le client intégré à GNOME, Evolution. La messagerie instantanée sera confiée à Empathy, qui remplace Pidgin depuis Ubuntu 9.10 (Karmic Koala).

KDE sera présent en version 4.4 et se basera sur Qt 4.6. Par rapport au KDE 3 présent dans Ubuntu 8.04, l’explorateur de fichiers par défaut n’est plus Konqueror (qui lui continue de faire office de navigateur web) mais Dolphin. Du côté de la bureautique, il est prévu d’intégrer la version 3.2.1 d’OpenOffice, dont la sortie pourrait intervenir peu de temps avant la finalisation de Lucid Lynx. Dans le cas où une version instable (ou du moins Release Candidate) venait à être intégrée, la version finale serait disponible par la suite dans les dépôts de mise à jour de la distribution.

Le planning complet du développement de Lucid Lynx, comprenant les dates prévues des sorties des versions Alpha, Beta, RC, puis Finale, ainsi que les dates des différents gels (freezes) est disponible sur la page LucidReleaseSchedule du wiki dédié au développement d’Ubuntu. Enfin, la liste des spécifications ciblées pour Lucid sont suivies sur Launchpad, la plateforme de développement d’Ubuntu.