Bonjour,

Dans ce contexte de «guerre de la rapidité» entre navigateurs, et surtout entre FireFox et Chrome, personne ne s'est trop intéressé à Konqueror, le navigateur web de KDE.

En effet, Konqueror utilise KHTML et KJS, qu'il est à peu près le seul à utiliser, donc ça intéresse moins de monde. De plus, KJS est très lent, ce qui fait que les chiffres de benchmarks Javascript sont moins beau que pour FireFox ou Chrome (à vue de nez et si mes souvenirs sont bons, Konqueror est à peine plus rapide qu'IE 8).

Néanmoins, une "petite" optimisation a été apportée hier dans la version SVN de KHTML, n'accélérant en rien le Javascript, mais plutôt le rendu HTML.

Voici les deux commits apportant cette modification :


r1096620 | ggarand | 2010-02-27 04:31:52 +0100 (sam 27 fév 2010) | 8 lignes
Chemins modifiés :
M /trunk/KDE/kdelibs/khtml/misc/loader.cpp
M /trunk/KDE/kdelibs/khtml/misc/loader.h

port KHTML to Andrea's excellent scheduler.

This, together with the next patch, greatly improves Konqueror's
objective speed (Page Loading Time) as well as the subjective speed
(Time To First Paint).
Our PLT was already very nice, but this just blows things off.
Will have to explain that in greater details, because it's just
beautiful :-)
------------------------------------------------------------------------
r1096621 | ggarand | 2010-02-27 04:32:03 +0100 (sam 27 fév 2010) | 5 lignes
Chemins modifiés :
M /trunk/KDE/kdelibs/khtml/khtml_part.cpp
M /trunk/KDE/kdelibs/khtml/khtmlview.cpp

improvements of resources scheduling and overall speed
progress of KIO over the past year(s) allow to greatly optimize the paint
suppression and initial layout delay algorithm.

TTFP is halved on most pages, without any flashing!


Quand j'ai vu ça, j'ai tout de suite recompilé les kdelibs, puis relancé Konqueror.

Tout est assez subjectif, mais la rapidité est bien là. Konqueror a toujours été assez lent, en affichant désespérément une page blanche avant que tout ne soit chargé, puis dessinant le tout lentement.

Ces modifications permettent d'une part de détecter plus vite quand une page peut être dessinée et qu'elle ne changera plus après (donc quand on a tout le HTML, le Javascript et la taille des images), pour pouvoir présenter la page plus rapidement à l'utilisateur.

Le résultat est saisissant sur Linuxfr (surtout la page d'accueil, avec les journaux et dépêches apparaissant au compte-goutte) : dès le bouton «Accueil» cliqué, la barre des menus du haut, l'image avec les pingouins, l'astuce et la dépêche mise à l'honneur apparaissent. Ensuite, les contenus arrivent un à un, suivi de près par leur image. Une fois tout chargé correctement, les petits boutons «Fin de surveillance» font leur apparition.

D'autres sites assez lourds et riches en contenu, tel le planet KDE, se chargent beaucoup plus vite et beaucoup mieux.

Cette modification permet donc de tirer parti de la rapidité de KHTML, sans être freiné par les KIO et le téléchargement d'autres machins. Ce n'est pas encore un Javascript rapide, mais ça rend tout de suite Konqueror bien plus utilisable (et petit effet de bord : quand vous démarrez Konqueror et qu'il restaure plein d'onglets, on sent largement le gain de vitesse qui fait qu'on arrive vite aux pages qu'on avait, et pas devant une fenêtre toute blanche).

Voilà. Ce sera disponible dans KDE 4.5.

> Lire le journal (69 commentaires, moyenne: 2,2).

Bonjour,

Pour la sortie de KDE 4.4, le site de KDE a été refait.

Juste un mot : sublime ! Il contient également plein d'informations, et je vous invite à cliquer sur les liens et à naviguer dans le menu. Vous aurez droit à des dizaines de screenshots, des explications, le tout avec un thème frais.

Quand je pense que hier, étant allé sur gnome.org, je m'étais dit que leur site était mieux. Et hop, le lendemain, KDE a un nouveau site :D !

Félicitations aux designers et à toute l'équipe de ce site, KDE reprend enfin sa communication en main et pourrait se relever de l'époque KDE 3 et KDE 4.0.

> Lire le journal (65 commentaires, moyenne: 3,1).

Bonjour,

Sous ce titre assez étrange et récursif s'annonce une excellente nouvelle pour la chère diversité à laquelle le Libre accorde tant d'importance.

Depuis quelques années, le projet LLVM essaie de créer une infrastructure de compilation, basée sur une représentation abstraite du code, indépendante de la machine. Le projet LLVM comporte également un «sous-projet» dénommé Clang, un compilateur pour les langages basés sur le C (C, C++, Objective-C et Objective-C++).

Les avantages de LLVM et de Clang par rapport à GCC sont les suivants :

• Une architecture en bibliothèques alors que GCC est un gros machin monolithique (plus tellement à partir de la version 4.5). Tout le monde peut développer d'autres bibliothèques et leurs clients, et réutiliser LLVM. Ainsi, LLVM est utilisé dans Gallium, OpenShiva, et encore quelques autres.
• La rapidité. Clang est largement plus rapide que GCC comme montré sur cette page
• Consommation limitée de RAM (il est maintenant possible de compiler en -j16 sur un double quad core HT avec seulement 2Gio de RAM sans que la RAM manque !)
• Fonctionnalités intéressantes pour le développeur (analyse de code, erreurs détaillées, etc)

Une page de comparaisons a été créé pour vous permettre de voir ce que Clang apporte.

Le C et l'Objective-C sont supportés depuis pas mal de temps, quasiment à un niveau de production. Le noyau FreeBSD est compilable par LLVM, ainsi que d'autres très gros projets.

Par contre, le C++ a toujours manqué à l'appel, et a été la bête noire de Clang. En effet, le C++ est un langage extrêmement complexe pour le compilateur (et les trolleurs diront aussi pour le programmeur), avec ses templates, ses classes, sont héritage multiples, les exceptions, etc.

Il y a quelques jours, une excellente nouvelle est tout de même arrivée sur le blog de LLVM : Clang sait se compiler lui-même !

C'est un grand pas, quand on sait que le code de LLVM est très complexe et utilise quasiment toutes les fonctionnalités du C++. Il est également très important : plus de 500 000 lignes (à en croire le billet cité ci-dessus).

C'est donc une belle avancée pour Clang. Dans quelques mois, il se pourrait que Clang compile de plus en plus de choses.

Des patches volent déjà pour compiler quelques programmes C++ utilisant Qt avec Clang. Malheureusement, bien que la compilation soit un succès, la liaison ne marche pas. En effet, Clang a encore du mal a gérer les symboles partagés de type «friend», très utilisés dans Qt pour les valeurs partagées (par exemple une chaîne nulle, un tableau vide, etc).

C'est cela qui provoquait les erreurs que je décrivait dans mon journal Clang arrive avec le C++, et ça va faire mal !. Merci d'ailleurs à tous ceux qui ont essayé de résoudre mon problème.

J'espère donc un jour pouvoir compiler Qt, puis KDE, puis tout mon environnement avec Clang.

D'ailleurs, pour parler de choses plus personnelles, j'ai encore toujours comme idée de mettre LLVM dans mon gestionnaire de paquets. J'ai réussi récemment à compiler le petit navigateur web Cream développé par une connaissance en GTK/C avec Clang, en produisant ce fameux fichier bytecode, sans toucher au moindre Makefile, uniquement en tunant les paramètres des autotools. Tout marche très bien et est très rapide.

De plus, Clang m'a également surpris. En effet, depuis un mois environ, j'essaie de développer un algorithme de différences binaires parfait, dans le sens qu'il produit le plus petit patch possible. Il n'y a pas encore de code source disponible, mais les informations sur les avancées se trouvent ici.

Bref, je m'égare. L'important ici est que j'ai utilisé Clang, et uniquement Clang, pendant tout le développement de l'application de test en C. J'ai ainsi pu profiter de sa vitesse (compilation en moins d'une seconde en -02, alors qu'une compilation de KDE tournant à côté, processeur chargé à 100%). J'ai également été très surpris par les optimisations qu'il fait. En effet, un simple -O2 m'a permis d'obtenir un exécutable plus rapide que celui produit par GCC 4.4 en -O2 ou -O3. Je n'ai plus les nombre, mais le bench prenait 0,9 secondes avec Clang, et 1,1 secondes avec GCC (grande valeur de 0,9, petite valeur de 1,1, mais quand-même).

Clang est donc plus que jamais un projet à garder à l'oeil, et qui évolue toujours plus vite :-) .

> Lire le journal (41 commentaires, moyenne: 2,9).

Bonjour,

Depuis la sortie de KDE 4.0, des milliers de gens se plaignent de sa lourdeur, et de ses performances aléatoires. En effet, autant il peut marcher fluidement sur un vieux Pentium 3 chez quelqu'un, autant un autre rapporte qu'il se traîne comme un éléphant sur une machine dernier cri.

Les pilotes graphiques ont été pointés du doigt dès le début, mais tout le monde n'a pas compris ce que cela impliquait. Il a été conseillé à beaucoup de personnes de désactiver les effets graphiques de Kwin, mais ça n'a quasiment rien corrigé la plupart du temps.

Fonctionnement de la couche graphique de Qt

Cette partie est un peu technique, mais pourrait vous intéresser. Elle se base sur les différents articles cités en haut de ce billet sur le blog de Trolltech.

Qt est une bibliothèque portable, qui s'occupe de beaucoup de choses, dont tout un système graphique (nommé Arthur, et j'insiste sur le fait que Qt est un framework, pas simplement une bibliothèque graphique). Du fait de la portabilité de Qt sur différents systèmes d'exploitations (GNU/Linux, Windows, Mac, des téléphones mobiles, etc), la couche graphique doit être adaptée à l'architecture cible.

Pour les applications, il n'y a rien à faire. C'est seulement Qt qui utilise en interne des backends.

Sous GNU/Linux, le backend X11 est utilisé. Il transforme les opérations de dessin de bas niveau de Qt (cercles, texte, images, etc) en instructions XRender, ce qui permet d'utiliser l'accélération matérielle de la carte graphique.

Un backend OpenGL est disponible pour quasiment toutes les architectures. Là, ce sont des shaders et des opérations OpenGL qui sont utilisées, pour encore mieux tirer profit de la carte graphique.

Il existe aussi des backends pour Mac OS X (Cocoa) et Windows (DirectDraw, mais on n'en parle pas beaucoup, donc je ne suis pas certain qu'il est disponible en production).

La faiblesse de XRender

Le problème vient justement du backend X11. D'ailleurs, ceux qui ont utilisé KDE sous Windows ont peut-être remarqué à quel point il est plus rapide sous cet OS que sous GNU/Linux, du moins graphiquement (changement d'onglet dans Konqueror, ouverture d'une application, navigation dans les menus, Plasma). En effet, X11 utilise XRender, qui accélère très bien les «grosses» opérations graphiques, comme par exemple un énorme cercle plein dessiné sur tout l'écran.

Malheureusement, ce n'est pas ce genre d'opérations utilisées par Qt. Dessiner chaque contrôle graphique d'une application Qt nécessite plusieurs dizaines d'opérations, même pour un simple bouton. Seul l'horrible thème Windows95, inclus avec Qt, est suffisamment simple pour profiter de XRender (un bouton est un rectangle avec 4 lignes dedans pour le relief, et du texte).

KDE, par contre, avec son thème Oxygen et ses effets en tous genres est bien trop complexe pour XRender. Dessiner un bouton Oxygen, avec son ombre, son relief, ses effets, la petite illumination nécessite plusieurs dizaines d'opérations graphiques, de petites opérations (une ligne de 3 pixels, etc). Ainsi, bien plus de temps est passé dans Qt et dans XRender pour préparer le dessin que dans la carte graphique pour le rendu. Il y a également bien plus de trafic entre l'application et le serveur X.

XRender est donc la source de la lenteur de KDE, et des petits freezes qu'on peut ressentir quand une lourde opération graphique est lancée (premier affichage d'une fenêtre, changement de bureau virtuel quand la composition est désactivée, changement d'onglet dans Dolphin, Konqueror ou autre).

OpenGL à la rescousse, ou presque

Le but du backend OpenGL est de corriger ce problème. Malheureusement, tout ne va pas comme les développeurs le souhaitent. OpenGL pose les mêmes problèmes que XRender (plus de temps passé à la préparation qu'au rendu), et est surtout très incomplet et très mal supporté avec des pilotes libres, se limitant parfois uniquement à OpenGL 1 alors que la version 3 est disponible depuis longtemps.

Le rendu avec OpenGL est donc tout aussi lent qu'avec XRender, bien plus lent parfois (expérience perso : inutilisable sur une ATI Radeon X1250 intégrée avec le pilote libre RadeonHD).

De plus, le backend OpenGL est encore quelque-peu expérimental, et des erreurs de rendu peuvent apparaître (zones floues ou bruitées, éléments absents). OpenGL ne supporte pas non-plus certaines éléments de l'API graphique de Qt, ce qui lui demande de faire le rendu lui-même. Le gain est nul, et même négatif puisqu'il faut rapatrier dans Qt l'image calculée par la carte graphique, ce qui est exessivement long.

La solution, Raster

Heureusement, Qt dispose d'un backend Raster. Ce backend traite uniquement des images en RAM, et fait tout lui-même, sans la moindre accélération matérielle.

Cela peut sembler sous-optimisé, mais c'est en fait le meilleur des backends. En effet, il n'y a aucune phase de préparation, et ce backend est optimisé pour tirer parti des instructions multimédia disponibles sur les derniers processeurs.

Il est également l'implémentation de référence, ce qui veut dire qu'il se comporte très exactement comme les développeurs de Qt le veulent.

Au final, il a tout pour lui. Il est extrêmement rapide, et très stable. Son rendu graphique est impeccable, et très approprié à ce que demande KDE, c'est à dire le rendu de nombreux petits éléments, dont des dégradés.

Utiliser le système raster

Qt est bien conçu, et tester Raster ne nécessite qu'une simple manipulation.

Il vous suffit de lancer une application à tester dans une console, en lui passant le paramètre «-graphicssystem raster». Par exemple

konqueror -graphicssystem raster

lance Konqueror en utilisant le mode Raster.

Si vous appréciez ce moteur, et que vous souhaitez l'utiliser (lisez cependant ce journal jusqu'à la fin, je n'ai pas encore tout dit), il vous faudra néanmoins recompiler Qt (aïe), en n'oubliant pas de passer «-graphicssystem raster» à la commande ./configure. Je vous conseille, si vous sautez le pas, d'utiliser KDE Qt, qui contient des patches intéressants. De plus, la manière de compiler décrite sur ce wiki vous permet de ne pas sâlir votre /usr, mais d'installer Qt dans votre /home.

Quelques inconvénients de Raster

Pour introduire cette partie, je vous conseille de jeter un oeil au journal Chromium est bien plus lent que FireFox (en passant au-dessus de tous les trolls bien entendu).

XRender a bien un avantage : il est léger en bande passante. L'application Qt ne fait que demander à Xorg de dessiner sa fenêtre, ce qu'il fait avec plaisir (perso: en consommant 400Mio de RAM au passage. Avec Raster, il n'en consomme plus que 26,7 Mio d'ailleurs :-) ). Il n'y a donc pas de transfert d'images, hors icônes et petites images utilisées ailleurs.

Avec Raster, c'est bien différent. Qt construit son image dans son coin, pixel par pixel (mais très rapidement et très proprement), puis l'envoie d'un coup à Xorg. En local, aucun problème. Un système de mémoire partagée est utilisée, et Xorg envoie directement le tout à la carte graphique, comme il fait avec les images qu'il produit lui-même. C'est même ce qu'il sait faire le mieux.

Par contre, sur le réseau, c'est plus embêtant de faire passer, à chaque modification d'une fenêtre (caractère tappé, etc), l'équivalent d'une grosse Bitmap non-compressée de la taille de la fenêtre.

Vous allez me dire que ce n'est rien, et que personne n'utilise le réseau. Vous avez raison, mais ce n'est pas tout.

NOTE : La partie qui suit semble ne plus se vérifier sur mon ordinateur, quand j'utilise Qt-KDE trunk. En activant le greffon KWin qui va bien, j'ai pu constater que seules les parties réellement modifiées d'une fenêtre sont envoyées à X, ce qui est très bien. Ce que je dis se rapporte à une version antérieure de Qt, que j'ai eu l'occasion de tester il y a quelques mois. J'avais remarqué ce comportement, mais rien ne me dit s'il se produit encore chez pas mal de monde. À prendre avec des pincettes donc, je ne peux vérifier, vous êtres prévenus.

En effet, le compositing (fenêtres molles, etc) devient quasiment insupportable. Xorg sait très bien dessiner des images directement à l'écran, et je dis bien directement.

Il faut savoir comment marche un gestionnaire de compositing comme KWin. Quand une fenêtre est modifiée, elle l'est sur une partie invisible de l'écran (en fait, KWin affiche une grosse fenêtre qui recouvre toutes les autres, et dans laquelle il fait son petit mélange, c'est spécial à imaginer, mais il fait ça). Xorg en avertit KWin, qui recopie le contenu modifié de la fenêtre, met à jour une texture OpenGL, et dessine le résultat en utilisant OpenGL.

Bien, excellent :) . Non, c'est nul pour notre cas ! En effet, Qt envoie des images de fenêtre complètes, donc KWin, pour chaque modification mineure d'une fenêtre, doit récupérer une image colosalle (Xorg ne sait pas que seul le petit bouton en bas à droite a été modifié, il recoit une grosse image, lui). Il lui faut donc récupérer cette image, la convertir en texture OpenGL, l'envoyer à la carte graphique, qui fait sa popotte avec.

Résultat ? C'est insoutenablement lent. Autant c'est foudroyant comme le tonnerre sans compositing, autant le compositing tue tout. C'est malheureusement inacceptable d'utiliser Raster si on tient à ses effets glossy.

NOTE : Fin de la partie douteuse

Il y a également un autre inconvénient, qui sera surtout ressenti par ceux possédant une petite configuration (pas d'instructions multimédia, vieux processeur, etc), et utilisant beaucoup Konqueror.

Le scroll est une accélération typiquement gérée par XRender, qui fait tout faire par la carte graphique. Le scroll est donc fluide et ne consomme que peu de processeur. En utilisant Raster, il faut, malgré les optimisations de Qt (cache de la page web par exemple) renvoyer fréquemment une grosse image, et dessiner de nouveaux éléments. Ça occupe bien plus le processeur, et ralentit le compositing. Pour éviter les ennuis, désactivez «Défilement doux» dans les options de Konqueror, ou de tout navigateur basé sur Qt (Rekonq, Arora, Opera (ne l'oublions pas))

Conclusion

Avec KDE-Qt trunk (4.7), KDE trunk (4.4.50), et Qt compilé en utilisant le système graphique Raster, mon environnement KDE pète le feux comme jamais, et tout est aussi fluide que ce qu'on peut vouloir. Même des applications reconnues poussives comme Krita, KWord et Konqueror marchent sublimement bien. KDE 4.4 apportant de jolis effets dans Oxygen, avec des animations discrètes, je peux témoigner de la rapidité graphique du truc : avec XRender, impossible de distinger le doux fondu qui se produit quand on change d'onglet, alors qu'en Raster, le CPU n'est même pas utilisé à 100% et c'est fluide.

Si vous faites partie de ces gens qui n'ont connu qu'un KDE poussif et lent depuis la version 4.0, et qui utilisez soit de vieux pilotes Intel, le pilote libre ATI, ou le pilote propriétaire nVidia, testez un peu la simple manipulation du «-graphicssystem raster». C'est rapide, et c'est du pur bonheur.

Je n'aime pas devoir recompiler Qt. Si quelqu'un a une autre technique (fichier de configuration global à Qt contenant le réglage, que je n'ai pas trouvé dans qt4-config), qu'il ne se prive pas d'en parler ici.

Bon amusement avec un KDE léger (la manipulation libère d'ailleurs une centaine de Mio de RAM occupés par X quand des applis lourdes comme KDevelop sont lancées, car seule une Pixmap gérée par Qt est prise en RAM, et pas plein de caches XRender).

> Lire le journal (51 commentaires, moyenne: 3,5).

Bonjour,

Ayant l'habitude de suivre le Planet KDE, je suis tombé sur un billet particulièrement intéressant : GTK+ made Qt.

L'auteur de ce billet propose de recréer une bibliothèque GTK+, mais utilisant au maximum Qt. Telle qu'il la présente, elle n'est pas binairement compatible, mais uniquement du point de vue des sources. Il a déjà des exemples qui tournent, et le travail semble correct.

Par contre, cette bibliothèque n'est pas encore du tout propre, et n'est qu'une ébauche. Toutes les vérifications faites par GTK ne sont pas faites, plein de trucs ne vont pas, etc.

Néanmoins, c'est une idée qui ne peut qu'être applaudie des deux mains, et est peut-être le futur projet libre de l'année. En effet, les promesses de ce genre de bibliothèque sont énormes : enfin des applications GTK parfaitement intégrées à Qt.

La méthode n'est peut-être pas la plus simple (le plus simple aurait été un backend GTK, comme il en existe pour Windows et Mac), mais il faut avouer que l'idée est séduisante, surtout si tout le boulot se fait à la compilation.

Par contre, du côté technique, ça promet d'être difficile. En effet, le C est très facilement utilisé depuis le C++, mais l'inverse est déjà nettement moins facile.

En tous cas, ce binding inattendu est vraiment très prometteur, et on ne peut qu'encourager l'auteur. Si vous connaissez Qt et GTK+, c'est un bon projet auquel participer, déjà rien que pour montrer que ça intéresse des gens.

Parlez-en, une nouvelle aire d'intégration commence peut-être !

Toutes mes félicitations à son auteur.

> Lire le journal (59 commentaires, moyenne: 2,3).

Bonjour,

Vous savez qu'outre KDE, un autre projet libre que j'aime particulièrement est Clang/LLVM, comme j'ai eu l'occasion de le montrer dans mes précédant journaux Clang-C++ a mangé du lion ! et LLVM dans un gestionnaire de paquets ?

LLVM est un projet important visant à mettre en commun la «partie basse» des compilateurs. Il utilise un langage abstrait (appelé bytecode) et génère un véritable binaire pour chaque architecture supportée. Il permet également d'excellentes optimisations, ainsi qu'une compilation juste-à-temps si nécessaire.

Clang est un compilation C, C++, Objective-C et Objective-C++ qui utilise LLVM comme couche basse. Il ne s'occupe ainsi que de la gestion du langage (et le fait bien), et permet à LLVM de faire les optimisations qu'il veut.

Le soucis de Clang a toujours été le C++. En effet, le langage C est très simple, et il n'est pas trop difficile de créer un compilateur pour lui (on en trouve même des petits comme exercices dans les livres de programmation, le SDK MS en contient un il me semble, et on en trouve énormément en libre).

Par contre, le C++ est largement plus complexe, surtout dans son utilisation avancée. Les classes, les fonctions virtuelles, les templates, le polymorphismes sont très complexes à gérer pour le compilateur.

Aujourd'hui, j'ai récupéré la version SVN de Clang et l'ai compilée. Je m'en suis alors servi pour compiler quelques petits programmes en C++, et compte encore le faire.

Tout d'abord, un simple fichier .cpp. La compilation se passe sans problèmes, pas de warnings. Par contre, la liaison échoue lamentablement pour une raison étrange, sans doutes une bibliothèque que Clang ne connaît pas.

J'essaie ensuite avec un programme C++ un peu plus complexe. Le cobaye de cette expérience est Setup, mon gestionnaire de paquets.

Le lance la compilation, ça compile deux trois fichiers (assez rapidement d'ailleurs), puis ça échoue sur l'un d'eux. Je regarde l'erreur, voit qu'il y a un problème dans les en-têtes de Qt, corrige (hackish : suppression de la ligne foireuse :-° ), et recommence.

La compilation se passe sans problèmes, même le moc, même ce qui utilise des templates, fonctions virtuelles, etc. Un beau fichier liblpackages.so est généré, la liaison ayant marché.

Ensuite, je passe au front-end Setup lui-même. Là aussi, je compile, ça me sort trois warnings que je corrige, puis j'essaie de lier. Là par contre, ça marche un peu moins bien : il manque plein de symboles, dont plein de trucs venant de Qt ! Pourtant, je me lie bien à QtCore, tout est ok. C'est donc soit un bug dans Clang, soit dans Qt.

Pour finir, je n'ai pas su voir si le programme se lance, mais c'est déjà une avancée magnifique par rapport à ce que j'ai testé il y a quelques mois (la compilation ne marchait pas). Dans quelques mois, il se pourrait qu'on aie un bon remplaçant à GCC. Il faut juste que j'arrive à compiler un truc pour voir si le code est plus lent ou plus rapide que ce que GCC génère.

Pourquoi j'ai mis «ça va faire mal» dans le titre ? Parce que Clang est vraiment super strict. En compilant en -Wall, il y a énormément de warnings très intéressants (ceci est plus rapidement fait comme cela, cela est boiteux, etc). Je compile Setup en -Wall -Werror, donc je dois corriger tous les warnings, pour que ça marche. Je les ai tous corrigés. Il y a aussi le fait que Clang n'accepte pas ce que GCC peut accepter. Il y aura donc plein de programmes qui seront cassés, mais une fois corrigés, ils seront bien plus propres.

En tous cas, bravo aux développeurs de Clang ! C'est un beau bébé qui commence à bien marcher.

> Lire le journal (12 commentaires, moyenne: 4,7).

Bonjour,

C'est avec un grand plaisir que je vous annonce la deuxième version Alpha du gestionnaire de paquets Setup, que je suis en train de développer.

Près d'un mois après la sortie de Setup 0.1-alpha0, cette nouvelle version amène un lot conséquent de nouveautés, et prépare Setup aux version bêta, rc puis finale.

Présentation rapide

Setup est un gestionnaire de paquets plus ou moins comme les autres, mais accordant de l'importance à ce que les autres délaissent, comme la facilité d'utilisation, la beauté, la rapidité. Néanmoins, la robustesse n'est pas en reste, et est particulièrement améliorée dans cette nouvelle version.

Setup peut également se définir comme «le gestionnaire de paquets de Madame Michu». En effet, tout est fait pour qu'il soit facile et agréable à utiliser, comme les métadonnées des paquets traduites, un affichage en couleur (dans la console), et une future interface graphique utilisant Shaman 2 comme front-end.

Une présentation plus poussée de Setup peut être trouvée dans mon précédent journal, dont le lien est donnée en introduction.

Changements de cette version

Cette version est sous le signe de la maturité, et Setup commence tout doucement à être utilisable. En gros, il installe, supprime et met à jour des paquets correctement.

• Suppression de paquets
• Mise à jour de paquets
• Abandon du script bash helperscript pour une solution plus robuste en C++
• Utilisation de GPGME et libarchive à la place des commandes tar et gpg
• Nouveau format de paquet, compression XZ encore plus efficace que le LZMA, et plus rapide. Paquets plus simples à créer (juste metadata.xml, plus besoin de tous les fichiers autour)
• Nouveau format de dépôts, plus complet, et utilisant une base de donnée. C'est la porte ouverte à plein d'améliorations, comme diverses statistiques, les Delta Packages, etc
• Abandon des scripts bash setup-dev (sepa et repoma), utilisation de Setup et de libpackages. Ainsi, un plugin pour KDevelop permettant de créer ses paquets directement depuis cet environnement est possible :) .
• Installation et affichage d'informations d'un paquet se trouvant hors des dépôts
• Commentaires, activation et signature optionnelle pour les dépôts
• Nouvelles progressions, et nouvelle architecture de progressions, plus robuste et complète.
• Correction de plusieurs dizaines de bugs et problèmes

La suite

Pour les prochaines version de Setup, seuls des détails sont prévus, normalement plus de refontes.

Il y aura par exemple la gestion des paquets sources, permettant à n'importe qui de télécharger un paquet, de le compiler et de l'installer, à la manière d'apt-source. Logram s'ouvrira alors à plus d'architectures.

Un backend Shaman 2 sera créé, pour proposer une interface graphique aux utilisateurs de Setup. C'est également là que Setup pourra prouver sa rapidité, dans une sorte de petit concours par rapport à Pacman (démarrage instantané ou presque, recherche de paquet en temps réel quand l'utilisateur tape des caractères, etc). Ce sera également une bonne occasion pour Shaman de vérifier qu'il est suffisamment indépendant de Pacman.

Un système de paquets Deltas doit encore être prévu, ce qui permettra de ne télécharger que les différences entre deux paquets (comme le Presto de Fedora). Ainsi, Logram pourra se permettre un cycle de mise à jour très rapide (par exemple, mise à jour quotidienne de KDE depuis tags/4.3, au lieu d'attendre les releases mensuelles).

L'annonce officielle

L'annonce officiel, comprenant une dizaine de captures d'écrans des nouveautés, et plus de détails, est disponible ici : Sortie de Setup 0.1-alpha1.

Bonne lecture, bons tests, et joyeux Noël !

> Lire le journal (24 commentaires, moyenne: 1,6).

Bonjour,

Journal bookmark, désolé : http://linux.slashdot.org/story/09/12/12/135209/

Slashdot nous informe que le projet GNOME compte se séparer du mouvement GNU, car il s'éloigne un peu de «l'intégrisme» de ce mouvement. En effet, GNOME met le Logiciel Propriétaire sur un pied d'égalité avec le Logiciel Libre (du moins c'est ce qui est dit dans l'article et les commentaires sur Slashdot).

Ce n'est pas encore fait, il doit y avoir un vote parmi les développeurs de GNOME.

Plus de détails sur l'article, je ne suis pas GNOME de trop près, mais c'est passé sur le Planet KDE (ils lâchent de temps en temps un petit troll par-ci par-là : http://www.purinchu.net/wp/2009/12/12/gnome-slashdot/ )

Voilà.

> Lire le journal (124 commentaires, moyenne: 2,8).

Bonjour,

Depuis quelques jours, j'accumule quelques petites nouveautés, qui n'ont pas assez d'importance à mes yeux pour valoir un journal.

Test de KDE 4.4

Comme à chaque fois, quand une version de KDE approche (généralement vers les premières bêta), je fais des tests et plein de screenshots que je partage avec les autres.

KDE 4.4 est une petite exception, car il y a tellement de nouveautés que je n'ai pas pu attendre, et que je vous montre déjà quelques petites choses. J'avais également fait un premier aperçu en septembre, mais il a disparu à cause d'un problème de serveur (qui ne se reproduira plus, bien entendu ;-) ).

J'aurais bien fait un joli copier/coller de ce que j'ai dit, mais comme Linuxfr ne permet pas de mettre des images dans les journaux, tant pis, vous aurez le lien pour voir tout ça : Ce que nous réserve KDE 4.4.

En résumé, KDE 4.4 utilisera Qt 4.6 (qui a fait l'objet d'une dépêche), Plasma est fluide et se dote d'un nouveau sélecteur de plasmoïdes, Nepomuk est enfin intégré correctement grâce au nouveau backend Virtuoso qui est enfin utilisable (avant il y avait Redland, horriblement lent, et Sesame2, en Java). Le thème de widgets Oxygen se dote d'effets et d'animations.

Fonctionnalité intéressante également, KWin permet de regrouper les fenêtres en onglets, et le tile est prévu soit pour KDE 4.4, soit pour KDE 4.5 (ça dépend s'il résiste au Hard Feature Freeze, le pauvre)

Krita demande de l'aide

Une nouvelle toute fraîche, ou presque, lue sur le Planet KDE. Krita devient intéressant, et quasiment utilisable par des artistes. Malheureusement, il est encore trop instable et lent pour une véritable utilisation.

Pour remédier à cela, l'équipe de développement de Krita compte offrir 3000€ à Lukáš Tvrdý, le développeur principal talentueux de Krita, pour qu'il travaille à temps plein sur Krita pendant 3 mois.

3 mois, à temps plein, ça va vraiment faire avancer les choses ! On peut se demander comment 3000€ lui suffiront, mais l'information court qu'habitant en europe de l'est, la vie y est moins cher (on parle du salaire moyen à 700€/mois, donc lui avec 1000€/mois, ça lui fera beaucoup).

Plus d'informations sur la page d'explication sur le site de Krita. Il ne reste plus que 1000€ à obtenir, tout est allé très vite, mais plus ils ont d'argent, plus Lukas pourra rester longtemps.

Setup et la mise à jour

Ah, moi et la pub pour mes propres projets, une grande histoire d'amour. C'est un journal, donc on va dire que je peux.

Depuis quelques minutes, le gestionnaire de paquets que je développe peut mettre à jour et supprimer des paquets. Ça paraît simple, mais c'est la concrétisation de mois de travail. Plus d'informations sur l'annonce officielle, avec tous les screenshots que vous pouvez vouloir. Les sceptiques quand au solveur de dépendance pourront également voir qu'il tient la route (je dis ça parce qu'on n'arrête pas de me dire que mon solveur n'est pas complet, sans jamais apporter un preuve (un ensemble de paquet) qui fait qu'il ne marche pas).

Bon jeudi soir, et dormez bien. Demain, vendredi !

> Lire le journal (25 commentaires, moyenne: 4).

Bonjour,

Aujourd'hui, j'ai le plaisir de vous annoncer que des mois de travail portent enfin leurs fruits. Après un début purement théorique, le gestionnaire de paquets que je développe pour le moment sort enfin à la lumière du soleil.

Cette version n'est pas du tout stable, et n'est là que pour montrer que le travail avance, mais peut déjà être testée, et appréciée. Certaines fonctionnalités critiques sont encore absentes (désinstallation, mise à jour), mais l'installation marche déjà correctement.

Qu'est-ce que Setup ?

Setup est le gestionnaire de paquets développé par le Projet Logram, dans le but de prouver qu'un gestionnaire de paquet peut être léger, puissant et rapide. Il sera en outre utilisé par notre future distribution.

Le but de Setup n'est pas d'être hyper puissant comme le sont APT ou Yum, mais bien de convenir à un usage de tous les jours sur des ordinateurs de bureau. La sécurité n'est pas en reste, mais certaines fonctionnalités lourdes ne sont pas prévues. En outre, un accent est mis sur la rapidité, voir «l'instantanéibilité» des actions possibles (bench en fin de journal)

Pourquoi ne pas reprendre RPM/Deb/Pacman/etc ?

La question a déjà été posée maintes et maintes fois. Le principal avantage de la création d'un nouveau gestionnaire de paquets est de pouvoir apprendre des erreurs des autres, sans devoir maintenir une compatibilité avec l'existant. Setup est une base solide sur laquelle on peut construire plein de choses, et est amené à devenir pas mal du tout.

Des «monstres» comme RPM ou DPKG/APT sont difficilement maintenables de par le fait qu'ils sont découpés en plein d'outils. Il existe plusieurs forks de RPM, et DPKG peut s'utiliser avec apt-get, aptitude ou dselect. Tout ceci fait qu'un bug trouvé dans un des outils doit être corrigé dans les autres. Créer un paquet RPM ou Deb est également complexe, alors qu'en créer un pour Setup est un jeu d'enfant.

De plus, un très mauvais point pour ces outils est que la partie «résolution des dépendances» est séparée de la partie «gestion des paquets». RPM peut être utilisé avec URPMI, yum, Zypper, voire apt-rpm. DPKG est utilisé par aptitude, apt-get ou dselect. Ceci empêche certaines goodies, très utilisées par Setup, comme le téléchargement et l'installation en parallèle, ainsi qu'un contrôle poussé de l'installation des paquets.

Quand aux gestionnaires de paquets comme Pacman et autres, ils sont très biens, et Setup s'en inspire. Ils ne semblent pas avoir les mêmes problèmes que les gestionnaires de paquets comme RPM, mais manquent parfois de quelques fonctionnalités, ou de rapidité. Un paquet ne peut par exemple pas «poser de questions» (DebConf-like) avec Pacman, ou alors ce n'est pas utilisé.

Pourquoi utiliser Setup, qu'a-t-il de mieux ?

Setup a un énorme avantage sur les autres : il est rapide, très rapide. La recherche d'un paquet, parmis 25 000, est instantané. La résolution des dépendances est inmesurable à l'échelle humaine, de même que toutes les autres opérations. Même la mise à jour de la base de donnée binaire, une opération extrêmement complexe (lecture de fichiers texte de 20 Mio, pré-résolution des dépendances, écriture binaire optimisée), ne prend qu'à peine plus de 2 secondes pour le contenu de Debian Testing, section main.

Setup est aussi une petite base de code simple et documentée (pour le moment en français, je fais trop de fautes d'anglais et personne n'a encore traduit mes commentaires). La gestion des paquets elle-même tient dans moins de 5500 lignes, le front-end en ligne de commande fait à peine plus de 1500 lignes. Le code lui-même est du C++ correctement organisé et utilisant Qt (question débattue plus loin).

Setup, bien que largement moins puissant que les autres gestionnaire de paquets, permet d'apprendre comment un programme de ce type fonctionne, et comment ça se crée. Setup est tout jeune, sa première ébauche datant du mois de septembre.

Utiliser Qt ? Quelle horreur !

Ce commentaire (ok, un peu moins sec), a été fait dans un précédent journal parlant de Setup. La raison évoquée était que dépendre de Qt pour «un programme de si bas niveau» est une aberration, surtout pour un serveur.

Plusieurs raisons font que Qt est utilisé, les voici :

• Logram n'est absolument pas destiné aux serveurs. Là-dessus, mettez une Debian ou une RedHat. Setup suit ce mouvement et ignore totalement ce milieu. Le serveur, c'est ok. C'est sur le desktop que Linux doit faire ses preuves. (note: je ne prétend nullement apporter quoique ce soit de spécial dans ce domaine, j'essaie, c'est tout)
• Qt est découpée en bibliothèques. Nous ne dépendons pas, pour le front-end console et la bibliothèque, de QtGui (la plus grosse partie de Qt, se chargeant de la GUI). Les seuls bibliothèques de Qt utilisées sont QtCore, QtXml, QtScript et QtNetwork.
• Qt est une dépendance «légère» par rapport à d'autres gestionnaires de paquet dont on se plaint bien moins. URPMI dépend de Perl, Portage est écrit en Python, etc. Ok, il y a bien RPM et la suite DEB qui sont en C, mais le C++ n'est pas plus lourd.
• Qt facilite énormément de choses. C'est une bibliothèque Libre (je le rappelle pour ceux qui sont trois guerres en retard) qui fournit énormément de code prêt à l'emploi. La gestion des téléchargements, des processus, du XML, des communications asynchrones, des tables de hash et des listes est gérée par Qt, gratuitement, ce qui permet de limiter les bugs au minimum.
• Qt est différent de KDE. Ce n'est pas parce que Setup dépend de Qt qu'il dépend de KDE, loin de là !
• Les performances ne sont absolument pas réduites, voir la suite. De plus, les éventuelles parties trop lentes en Qt sont remplacées par du C++ STL, comme par exemple la gestion des fichiers (un fichier texte de 20Mio, c'est un peu trop pour Qt). On n'est pas obligé de faire du 100% Qt, on peut prendre ce qu'on veut, et optimiser le reste

Les performances de Setup

Voici une suite de commandes avec leur résultat et le temps qu'elles prennent, le tout mesuré sur un ordinateur d'age moyen composé d'un AMD Athlon 64 X2 4000+ (2,4Ghz) et de 2Gio de RAM. Cette machine est certes assez puissante, mais ça va. La quantité de RAM importe peu, Setup étant très léger sur cet aspect (l'opération la plus lourde, lancée dans Valgrind, ne prend que 50Mio. Sans Valgrind, 35Mio à peu près sont utilisés, mais c'est difficile à mesurer tant Setup est rapide).

Attention, cette partie est un peu longue, Setup pouvant afficher pas mal de choses.

1. Mise à jour de la base de donnée binaire

Un dépot local, contenant les 28101 de la future Ubuntu LTS, portés grâce à un script Python maison, est importé dans la base de donnée binaire comme suit :

$ time ./setup -R /tmp/setup update
[0/6] Téléchargement de /home/steckdenis/repo/dists/experimental/x86_64/packages.lzma
gpg: Signature faite le mer 25 nov 2009 13:41:39 CET avec la clé RSA ID 47798B4B
gpg: Bonne signature de « Logram Repository »
[1/6] Téléchargement de /home/steckdenis/repo/dists/experimental/x86_64/translate.fr.lzma
gpg: Signature faite le mer 25 nov 2009 13:41:39 CET avec la clé RSA ID 47798B4B
gpg: Bonne signature de « Logram Repository »
[2/6] Téléchargement de /home/steckdenis/repo/dists/experimental/all/packages.lzma
gpg: Signature faite le mer 25 nov 2009 13:41:39 CET avec la clé RSA ID 47798B4B
gpg: Bonne signature de « Logram Repository »
[3/6] Téléchargement de /home/steckdenis/repo/dists/experimental/all/translate.fr.lzma
gpg: Signature faite le mer 25 nov 2009 13:41:39 CET avec la clé RSA ID 47798B4B
gpg: Bonne signature de « Logram Repository »
[4/6] Téléchargement de /home/steckdenis/repo/dists/ubuntu/x86_64/packages.lzma
gpg: Signature faite le dim 22 nov 2009 13:57:46 CET avec la clé RSA ID 47798B4B
gpg: Bonne signature de « Logram Repository »
[5/6] Téléchargement de /home/steckdenis/repo/dists/ubuntu/x86_64/translate.fr.lzma
gpg: Signature faite le sam 21 nov 2009 10:06:48 CET avec la clé RSA ID 47798B4B
gpg: Bonne signature de « Logram Repository »
[0/6] Mise à jour de la base de donnée : Lecture des listes
[1/6] Mise à jour de la base de donnée : Génération de la liste des paquets
[2/6] Mise à jour de la base de donnée : Écriture des chaînes de caractère
[3/6] Mise à jour de la base de donnée : Écriture des traductions
[4/6] Mise à jour de la base de donnée : Enregistrement des dépendances
[5/6] Mise à jour de la base de donnée : Enregistrement de données supplémentaires

real 0m2.406s
user 0m1.954s
sys 0m0.298s


C'est le traitement le plus lourd, équivalent de «apt-get update». Pas spécialement plus rapide que le reste, mais déjà pas mal, surtout que cette lenteur fait gagner beaucoup plus tard.

2. Recherche de paquets

Maintenant, affichons tous les paquets. C'est un autre traitement particulièrement lourd, nécessitant l'instanciation de 28 000 classes. La mémoire et le cache sont clairement ici le goulot d'étranglement :

$ time ./setup -R /tmp/setup search '*' | wc -l
28105

real 0m3.072s
user 0m2.795s
sys 0m0.249s


Heureusement, une recherche normale ne prend que quelques centièmes de secondes (équivalent de «apt-cache search») :

$ time ./setup -R /tmp/setup search galeon
galeon 2.0.7-1ubuntu2 GNOME web browser for advanced users
galeon-common 2.0.7-1ubuntu2 data for the galeon web browser

real 0m0.076s
user 0m0.055s
sys 0m0.007s


C'est agréable à utiliser, je peux vous le dire. Si tous les autres gestionnaires de paquets faisaient autant !

3. Métadonnées

Testons maintenant la rapidité avec laquelle Setup peut afficher des informations sur un paquet, l'équivalent de «apt-cache showpkg». Le "-C" permet d'afficher également le changelog. Pour réduire les délais ne provenant pas de Setup, un dépôt local est utilisé, pour ne pas devoir télécharger les métadonnées :

$ time ./setup -R /tmp/setup -C showpkg initng
Nom : initng
Version : 0.6.99+git20091106~1
Titre : Système de démarrage Init-ng
Logiciel graphique : Oui
Section : base
Distribution : experimental
Status : Non-installé
Téléchargement : 190 Kio
Taille installée : 420 Kio
Dépôt d'origine : repo
Paquet source : initng
Licence : GPL
Mainteneur : steckdenis
Description courte : Système de démarrage init-ng, remplaçant de SysVInit

Description longue :

Initng est un nouveau système de démarrage corrigeant les différents problèmes du vieilissant SysVInit. Entre autres, il permet de démarrer les services en parallèle, ce qui peut drastiquement réduire le temps de démarrage (si un processus attend 4 secondes avant de faire quelque-chose, un autre peut déjà travailler).

Initng permet également une personnalisation du démarrage plus poussée, et une plus grande légèreté. Ses fichiers de configuration sont facilement éditables, et Logram propose un outil pour le gérer.

Dépendances :
Légende : D: Dépend S: Suggère C: Conflit P: Fourni R: Remplace N: Est requis par

D: libinitng (= 0.6.99+git20091106~1)
N: initng-plugins (= 0.6.99+git20091106~1)

Versions disponibles :
Légende : * = Disponible, I = installée, R = supprimée

* 0.6.99+git20091106~1 Système de démarrage init-ng, remplaçant de SysVInit


Historique des versions :

0.6.99+git20091106~1 (steckdenis), 14/11/09 00:00

Ajout des questions

0.6.99+git20091106~1 (steckdenis), 9/11/09 00:00

Ajout des informations des fichiers qui doivent aller dans __LOGRAM

0.6.99+gitNov62009~1 (steckdenis), 23/10/09 00:00

Modification du changelog

0.6.99+gitSep202009~1 (steckdenis), 17/10/09 00:00

Première version


real 0m0.058s
user 0m0.008s
sys 0m0.010s


4. Solveur de dépendances

Maintenant, testons la rapidité du solveur, d'abord sur une petite requête, puis sur une grosse installation :

$ time ./setup -R /tmp/setup add initng-plugins
Paquets qui seront installés ou supprimés :
Légende : I: Installer R: Supprimer U: Mettre à jour P: Supprimer totalement

I: initng-plugins 0.6.99+git20091 Système de démarrage init-ng, modules supplémentaires
I: initng 0.6.99+git20091 Système de démarrage init-ng, remplaçant de SysVInit
I: libinitng 0.6.99+git20091 Système de démarrage init-ng, bibliothèques partagées

Solution 1 sur 1, de poids 0. Téléchargement de 279 Kio, installation de 910 Kio
Accepter (y), Suivante (n), Précédante (p) ou Annuler (c) ?
real 0m0.038s
user 0m0.015s
sys 0m0.011s


Pas mal, je connais des gestionnaires de paquets qui font pire. Voici maintenant une résolution bien plus complexe, utilisant les paquets Ubuntu :

$ time ./setup -R /tmp/setup -S off add vim
Paquets qui seront installés ou supprimés :
Légende : I: Installer R: Supprimer U: Mettre à jour P: Supprimer totalement

I: vim 7.2.245-2ubuntu Vi IMproved - enhanced vi editor
I: vim-common 7.2.245-2ubuntu Vi IMproved - Common files
I: libc6 2.10.1-3ubuntu1 GNU C Library:Shared libraries
I: libc-bin 2.10.1-3ubuntu1 GNU C Library:Binaries
I: libgcc1 4.4.2-2ubuntu1 GCC support library
I: gcc-4.4-base 4.4.2-2ubuntu1 The GNU Compiler Collection (base package)
I: tzdata 2009r-1ubuntu1 time zone and daylight-saving time data
I: debconf 1.5.28ubuntu1 Debian configuration management system
I: debconf-i18n 1.5.28ubuntu1 full internationalization support for debconf
I: liblocale-gette 1.05-4build1 Using libc functions for internationalization in Perl
I: libtext-iconv-p 1.7-2 converts between character sets in Perl
I: perl-base 5.10.0-24ubuntu minimal Perl system
I: libtext-wrapi18 0.06-7 internationalized substitute of Text::Wrap
I: libtext-charwid 0.04-6 get display widths of characters on the terminal
I: findutils 4.4.2-1 utilities for finding files--find, xargs
I: vim-runtime 7.2.245-2ubuntu Vi IMproved - Runtime files
I: dpkg 1.15.4.1ubuntu1 Debian package management system
I: libacl1 2.2.48-1 Access control list shared library
I: libattr1 2.4.44-1 Extended attribute shared library
I: libgpm2 1.20.4-3.2ubunt General Purpose Mouse - shared library
I: libncurses5 5.7+20090803-2u shared libraries for terminal handling
I: libpython2.6 2.6.4-1ubuntu1 Shared Python runtime library (version 2.6)
I: python2.6 2.6.4-1ubuntu1 An interactive high-level object-oriented language (version 2.6)
I: python2.6-minim 2.6.4-1ubuntu1 A minimal subset of the Python language (version 2.6)
I: libssl0.9.8 0.9.8g-16ubuntu SSL shared libraries
I: zlib1g 1.2.3.3.dfsg-15 compression library - runtime
I: mime-support 3.46-1ubuntu1 MIME files 'mime.types' & 'mailcap', and support programs
I: libbz2-1.0 1.0.5-3 high-quality block-sorting file compressor library - runtime
I: libdb4.7 4.7.25-7ubuntu2 Berkeley v4.7 Database Libraries [runtime]
I: libncursesw5 5.7+20090803-2u shared libraries for terminal handling (wide character support)
I: libreadline6 6.0-5 GNU readline and history libraries, run-time libraries
I: readline-common 6.0-5 GNU readline and history libraries, common files
I: libsqlite3-0 3.6.16-1ubuntu1 SQLite 3 shared library
I: libselinux1 2.0.88-1 SELinux runtime shared libraries

Solution 1 sur 1, de poids 0. Téléchargement de 23 Mio, installation de 83 Mio
Accepter (y), Suivante (n), Précédante (p) ou Annuler (c) ?
real 0m0.037s
user 0m0.017s
sys 0m0.010s


Installer des paquets avec plus de dépendances est normalement possible, mais le script de portage Ubuntu vers Setup laisse quelques imperfections (des paquets qui n'existent pas par exemple, ou des conflits étranges). Cette résolution des dépendances montre l'exactitude des solutions trouvées (ce n'est pas loufoque), et la rapidité. 37 centièmes de seconde, c'est très rapide !

5. Installation

L'installation en elle-même est rapide, mais difficile à démontrer pour les raisons suivantes :

• Les paquets Ubuntu ne peuvent être installés par Setup. Ce «port» n'est qu'un hack immonde visant à tester le solveur.
• Les paquets que j'ai créés sont des paquets de tests, posant des «questions» (comme DebConf). Déduire mon temps de réaction serait trop imprécis pour obtenir une mesure fiable

La seule solution est d'installer le seul paquet qui appartient à Logram et ne pose pas de questions : libinitng. Pour avoir tout de même une résolution des dépendances, libinitng-dev (qui dépend de libinitng) sera installé également. Il ne pose pas non-plus de questions.

$ time ./setup -R /tmp/setup add libinitng-dev
Paquets qui seront installés ou supprimés :
Légende : I: Installer R: Supprimer U: Mettre à jour P: Supprimer totalement

I: libinitng-dev 0.6.99+git20091 Système de démarrage init-ng, fichiers de développement
I: libinitng 0.6.99+git20091 Système de démarrage init-ng, bibliothèques partagées

Solution 1 sur 1, de poids 0. Téléchargement de 168 Kio, installation de 400 Kio
Accepter (y), Suivante (n), Précédante (p) ou Annuler (c) ?
Installation des paquets...

[0/2] Téléchargement de libinitng-dev
[1/2] Téléchargement de libinitng
[0/2] Installation de libinitng-dev
[1/2] Installation de libinitng

Paquets installés !


real 0m0.139s
user 0m0.058s
sys 0m0.086s


Vous voyez que les téléchargements et les installations sont faits en parallèle. Ainsi, pas de temps perdus (les téléchargements peuvent être sur plusieurs mirroirs, si jamais il y en a un qui est lent. Les installations peuvent utiliser plusieurs coeurs). Le tout est très rapide, et marche. Les fichiers sont installés dans /tmp/setup, pour éviter de sâlir la distribution hôte.

6. Fichiers d'un paquet installé

On peut ensuite récupérer la liste des fichiers installés par un paquet :

$ time ./setup -R /tmp/setup files libinitng-dev
/tmp/setup/usr/share/doc/initng/initng-chart.png
... Je vous fais grâce des 100 lignes ici ...
/tmp/setup/usr/include/libinitng-0.7/initng/event/all.h
/tmp/setup/usr/include/libinitng-0.7/initng.h

real 0m0.012s
user 0m0.005s
sys 0m0.004s


Conclusion

J'espère que lire ce journal ne vous a pas trop ennuyé. Je ne pense pas qu'une dépêche soit nécessaire, du fait que ce n'est que la sortie d'une version Alpha d'un programme peu connu. J'espère que vous trouverez un intérêt à Setup. Pour plus d'informations, lisez l'annonce officielle de la sortie, avec des détails moins techniques mais plus logistiques (et aussi une grosse simplification des choses pour être compréhensible par plus de monde).

Merci de m'avoir lu.

PS: Ce journal s'adresse avant tout à ceux qui s'intéressent à Setup, et je sais qu'il y en a (ils se sont manifestés dans les autres news). Il n'a pas pour but de me vanter, de vanter Setup, de faire de la pub, etc. J'autorise tout le monde à m'ignorer royalement :-) .

> Lire le journal (31 commentaires, moyenne: 4,4).

Bonjour,

Cela fait quelques temps que je n'ai plus fait de journaux, et cette fois-ci, ce ne sera pas un journal élogieux sur un projet sujet à troll que j'aime particulièrement.

Aujourd'hui, je vais vous proposer le fruit de plusieurs mois de travail, le tout présenté correctement, je l'espère, et Libre, bien entendu.

Le gestionnaire de paquetages Setup

Comme annoncé dans ce journal, je travaille depuis quelques temps sur un gestionnaire de paquets. Le but, au lieu de récupérer l'existant, est de se baser sur du propre.

Le gestionnaire de paquet est quasiment utilisable (il installe des paquets), mais est encore loin d'être fini. Il propose néanmoins déjà quelques fonctionnalités normales ou intéressantes que voici :

• Gestion des dépôts multiples de logiciels, de plusieurs types (distants et locaux pour le moment, mais bientôt sur CD/DVD, etc). Le FTP est géré
• Résolution des dépendances avec le système par branches décrit dans mon journal (lien plus haut), et qui marche
• Installation des paquets
• Signature des métadonnées du dépôt avec une clef GPG, somme de contrôle SHA1 pour tous les fichiers téléchargés
• Toute petite infrastructure de messages entre les paquets et l'utilisateur. Au menu pour ce week-end : gestion complète de tout ça sous forme de questions stockées dans un fichier XML, à la manière de debconf
• Affichage de plein d'informations, localisées dans la langue de l'utilisateur (pour le moment juste le français et un tout petit peu d'anglais)

Ça, tous les gestionnaires de paquets le font plus ou moins. La différence, c'est que Setup fait ça en moins de 4000 lignes, bibliothèque de gestion des paquetages et front-end console compris. Le tout est relativement léger, bien que pas encore optimisé.

Ainsi, on a une base propre et simple sur laquelle construire l'avenir des gestionnaires de paquets. La méthodologie est la même que celle utilisée par KDE : tout refaire, mais suffisamment bien pour que les modifications soient plus faciles à faire, et ainsi pouvoir amener des choses intéressantes.

Setup est codé en C++ et utilise Qt. Pourquoi ce bloat ? Parce que Qt (dont le module GUI n'est pas utilisé) factorise suffisamment le code pour permettre de créer un Setup léger de 4000 lignes, et comporte des modules très intéressantes :

• QtCore pour la base et plein d'autres choses. Une table de hash avec Qt, c'est du bonheur. Parser un fichier de configuration, c'est super simple. Gérer des options, un jeu d'enfant, etc
• QtNetwork, qui permet, en ne dépendant ni de GNOME ni de KDE, de permettre à l'utilisateur d'utiliser des dépôts HTTP, FTP, NFS, et tout ce que QtNetwork peut gérer (il est prévu pour une future version de Qt de baser QtNetwork sur GVFS ou KIO, suivant le DE utilisé en dessous. Que du bon)
• QtScript, qui permet de scripter Setup. Pour le moment, seul la "pesée" des branches peut être contrôlé. Ainsi, on peut en modifiant un script choisir si on préfère télécharger le moins, installer uniquement des paquets stables, etc. Sachant que c'est du script ECMAScript, la syntaxe est suffisemment riche pour permettre un équivalent du APT Pinning, etc
• QtXml, pour lire les métadonnées (descriptions, mais aussi icône, changelog, etc)

Le résultat est disponible en téléchargement, et tester Setup est expliqué en détail sur le site flambant neuf de Logram. Normalement, ça marche, j'ai testé. S'il y a des erreurs, signalez-les moi. Si vous sortez des sentiers battus, il se pourrait que quelque-chose ne marche pas (la mise à jour de la BDD après installation est encore quelque peu fragile, la suppression n'est pas gérée).

Et comme pas mal d'entre vous m'avez posé pas mal de questions sur le fonctionnement de Setup, j'ai pensé à vous, et rédigé une documentation complète sur le fonctionnement interne de Setup et de sa base de donnée. C'est, je crois, le seul qui existe en français.

Travail collaboratif d'un projet dans un environnement de rêve

Pour ceux qui suivent un peu l'histoire de Logram, l'environnement de bureau et distribution que je développe, vous avez pu remarquer que le site a changé.

En effet, cela fait depuis 3 ou 4 mois que je code cette nouvelle version, en parallèle à Setup. Logram dispose maintenant d'un site aux fonctionnalités de pointe, intégrées au sein d'un même environnement :

• Un forum plus que convenable avec modération, sondages, gestion du lu/non-lu, abonnement aux sujets, permissions, etc
• Un wiki correct et suffisant, avec historique des pages, droits, protection, privatisation (ok, les moules n'aiment pas ce mot), etc. Il ne vaut pas MediaWiki (utilisé par Wikipédia), mais c'est correct pour l'utilisation qu'on en fait
• Un webSVN basique mais permettant de directement montrer aux gens du code. Ainsi, ça encourage les membres à participer, du fait qu'ils voient les modifications de code en direct
• Un système de demandes permettant de gérer les bugs, les demandes de code, les idées, et tout ce qu'on veut, avec gestion des sous-demandes, demandes liées, importance, assignation, fichiers liés, et des dizaines d'autres détails qui rendent la vie agréable
• Un espace de téléchargement basique permettant de vite télécharger un truc
• La gestion des paquets de Setup est intégrée au site. C'est comme packages.debian.org, mais en mieux intégré au reste, et avec un design plus "frais"
• Un système de messagerie privée à plusieurs participants
• Un système d'envoi de fichiers avec gestion des dossiers et des quotas
• Un système de gestion des nouvelles, publiques ou privées (équivalent Linuxfr : dépêches ou journaux), avec validation, modération, gestion du workflow (ici on peut éditer un journal en ligne, on peut aussi le dé-publier, et gérer ça comme un blog)

Pourquoi je me permet de faire de la pub pour mon site !? Et bien, c'est simple : il est disponible pour tout le monde sous GNU GPL, avec quelques fichiers dans le domaine public (templates), et quelques fichiers en CC-By-Sa (images, design, icônes Oxygen réutilisées).

De plus, ce site est intéressant du fait qu'il ne suit pas les conventions. En effet, il est développé en Python et utilise le framework Django. Du côté serveur, ce n'est pas Apache mais Nginx qui tourne, largement plus rapide (on peut servir 20 pages par secondes sur la page d'accueil, alors que Apache en WSGI ne dépasse pas 6 pages par secondes, sur le même serveur hardware).

Le code est librement téléchargeable, et consultable dans notre WebSVN. Des rapports de bugs ont déjà été remplis, la méthode pour tester est détaillée (besoin de Django, MySQL, et quelques dépendances), et normalement ça marche.

Django découpe suffisamment en modules pour permettre de remplacer la gestion des paquets de Logram par n'importe quelle autre gestion. Le but de cette ouverture est de permettre aux autres distributions, ou aux autres projets, de bénéficier d'une forge de qualité intégrant de bons outils (par exemple, un forum correct, introuvable sur les autres forges). L'administration est encore un peu compliquée, mais le projet est jeune. C'est vraiment un truc que j'ai développé pour les autres avant de le faire pour moi, le fait que Logram l'utilise est un simple "bonus".

Si un projet Libre, de préférence francophone (parce qu'on n'a pas encore totalement fini le support multi-lingue), genre Wormux, a besoin d'un site web, j'espère que cette version conviendra. Si vous avez des demandes, je suis à l'écoute. Par contre, je ne pourrai pas aider pour le support, je n'ai malheureusement pas le temps. Il faudra un peu se débrouiller (mais normalement, le code est pris en main en une journée)

Bonne découverte.

> Lire le journal (103 commentaires, moyenne: 2,6).

Bonsoir,

Aujourd'hui, je vais vous faire part de mon récent test de la distribution Chakra, qui est une Arch Linux sur laquelle se trouve un KDE légèrement modifié, des outils graphiques et un installateur graphique.

Première étape : télécharger la distribution. C'est encore assez rapide, et l'image ISO va également sur une clef USB. Je place donc cette ISO sur ma clef USB, et reboot dessus.

Le démarrage est rapide, et j'arrive sur un magnifique environnement KDE ressemblant quasiment à l'original. Je remarque que le gestionnaire de paquetages graphiques (qui s'appelle Shaman) me demande de mettre à jour la distribution. Un peu idiot sur un LiveCD, ça prouve qu'il a été fait à l'arrache (normal en fait, Chakra étant encore expérimentale).

Je lance l'installateur graphique, qui est d'une beauté assez rare. Il dispose d'un thème noir bien léché et complet, et est particulièrement clair. La partie formattage est rapide et facile, et ils ont eu la bonne idée d'utiliser KPartitionManager pour ce faire. Fini donc les gestionnaires de partitionnements douteux et la duplication des efforts, un logiciel de qualité est ici utilisé (c'est le GParted de KDE), et il est parfaitement intégré à l'installateur.

Viennent ensuite les quelques options, dont certaines qui sentent le Arch Linux à plein nez (configuration de son ramdisk par exemple). Tout se déroule bien, je clique sur Installer.

Là, je me retrouve devant une barre de progression, bien léchée elle aussi, et des screenshots de KDE qui défilent devant moi. C'est encore un point que je donne à Chakra, car on n'y pense pas, mais le nouvel utilisateur de Linux aime bien découvrir son environnement pendant que ça installe :) .

Une fois installé, je redémarre. Je découvre alors à quel point Arch Linux démarre vite. Par contre, pas de boot graphique. Ça ne va pas plaire à Madame Michu.

J'arrive sur le bureau, déjà bien complet. Je lance les 150 mises à jour (alors que le LiveCD date du début du mois, ah ces distribs en rolling release), attends un peu, puis ça se termine. Je lance donc le gestionnaire de paquetages graphiques, Shaman, et découvre un outil de très bonne facture.

Il utilise Qt, s'intègre bien à KDE, et utilise même les notifications de l'environnement quand il a un truc à afficher ! Il est également intégré à l'outil de mise à jour, qui se stoppe quand Shaman est lancé. Ça c'est de la finition !

Je sélectionne quelques paquets (Amarok 2, KOffice), installe le tout. L'installation est largement plus rapide que l'outil poussif qu'est URPMI en interface graphique, mais encore bien loin de Apt et Synpatic (je vais finir par croire qu'on ne fait pas plus rapide).

Petite signature Arch ici : je voulais installer les habituels fichiers de développement de Qt, subversion, les build-essentials, et me rend compte qu'ils ne sont pas dans Shaman. Etonné, je lance un "gcc --version", et découvre que GCC est installé ! De même pour g++. Ensuite, j'explore /usr/include, et découvre toutes les en-têtes de KDE et de Qt. Je me rappelle alors le bon vieux troll «Faut-il installer ou non les fichiers de développement avec les bibliothèque», ainsi que le fait que Arch fonctionne ainsi. Subversion est également installé, seul Make manque à l'appel.

Je l'installe, vais dans mon dossier des sources de Logram, un petit qmake, make, su -c "make install", et c'est bon. Magnifique, je n'ai jamais mis en place mon environnement de développement sur une nouvelle distribution aussi vite ! Encore un point pour Chakra, même si c'est moins Michu-compliant.

Pour ce qui est de l'utilisation, le KDE est parfaitement stable et bien à jour (même la dernière bêta de KDevelop se trouve là-dedans). Tout est superbement rapide, même ce qui était lent sous Mandriva, Ubuntu, openSuSE et Debian. Comment font-ils ?

Par exemple, la suppression d'un mail dans KMail est instantané, et loin de là pour les autres distributions. Le démarrage de KDE est foudroyant, alors qu'il prend son temps avec les autres. Plasma est réactif, les effets de composition de KWin sont utilisables, même KOffice démarre vite ! Encore une fois, comme est-ce possible ?

Tout ce que je sais, c'est que je vous conseille de tester Chakra. Il est encore dit sur le site que c'est une distribution expérimentale, mais je lui prédit un grand avenir. Chakra prouve qu'on sait faire une belle distribution, basée sur KDE, avec les outils de Arch Linux, et que tout se passe bien. Il y a beaucoup de paquets dans la distribution, tous dans leur dernière version, le tout est stable et bien pensé, bref j'adore.

Chapeau à ceux qui ont créé tout ça, c'est magnifique. Moi en tous cas, je garde ma Mandriva de côté pour le moment (j'en avais vraiment marre de me dire «Oh non, encore devoir installer un paquet dont je ne connais ni le nom ni la description, je vais devoir passer par cette interface graphique qui prend 1m50 à se lancer, et qui se relance avant de quitter !»).

PS: Et pour le titre pas tout à fait français, c'est en petit rappel avec un post passé il y a quelque temps et dont je ne me souviens plus qui utilisait cette construction. C'est comme les «xxx c'est bon, mangez-en» qui font partie de la culture Linuxfrienne, au même titre que le «support de qualitai» passé dans une dépêche.

> Lire le journal (38 commentaires, moyenne: 1,9).

Bonjour,

Ceux qui touchent de temps en temps aux compilateurs savent que le compilateur libre le plus utilisé est GCC. Ceux d'entre eux qui sont également de fins trolleurs savent que ce compilateur est fermé sur lui-même du côté des extensions.

En effet, GCC se comporte comme un seul gros bloc de code duquel rien ne sort et dans lequel rien n'entre. Une fois son GCC compilé, on ne peut le modifier qu'en touchant à des fichiers de configuration.

D'un autre côté, son concurrent, la suite Clang/LLVM, tout aussi libre (et les trolleurs encore plus fins diront qu'il est même plus libre), en partie développée par Apple propose depuis déjà des lustres l'utilisation d'extensions pour personnaliser son compilateur.

Cette différence a toujours été reprochée à GCC, et l'excuse mise en avant est que Richard Stallman ne veut pas d'extensions pour éviter que tout logiciel propriétaire ne puisse utiliser GCC. C'est donc un problème "philosophique" bien ancré.

Aujourd'hui, j'ai voulu voir ce que nous prépare la future version 4.5 de GCC. Je me rends donc sur la page des spécifications de cette version, lis un peu le tout, et tombe sur un dernier paragraphe en dessous.

Ce paragraphe m'étonne vraiment, car il dit que GCC supportera les extensions. Il ne s'étend pas sur le sujet, mais «It is now possible to extend the compiler without having to modify its source code. A new option -fplugin=file.so tells GCC to load the shared object file.so and execute it as part of the compiler. The internal documentation describes the details on how plugins can interact with the compiler.» semble très encourageant.

Alors, est-ce que ce changement est définitif ? Et surtout, qu'est-ce que ça va changer ? On aura peut-être plein de petites extensions pour personnaliser ses compilations. Gentoo va peut-être faire des petits machins avec ça (c'est une distribution source, donc les compilateurs, ça la connaît). Il y aura peut-être encore d'autres applications, utiles ou pas.

En tous cas, c'est un important changement de direction de la part des développeurs de GCC !

> Lire le journal (98 commentaires, moyenne: 3).

Bonjour,

Sous ce titre particulièrement trollesque, je vais tenter de donner de véritables arguments en faveurs de deux grosses pièces du Logiciel Libre que j'utilise, c'est à dire KDE et KOffice.

Oui, le premier comprend le deuxième, mais on va dire que par "KDE", j'entends l'environnement lui-même. KOffice tourne sous Windows, Mac, avec GNOME, Xfce, etc.

Oublier ce qu'on connaît

Qui n'a pas déjà testé un nouveau programme, et n'a pas aimé le fait de devoir perdre ses habitudes ? Avec les deux logiciels que je cite, c'est encore plus fort. Quand j'ai testé KDE pour la première fois, j'ai failli en être dégoûté. Quand j'ai testé KOffice 2 pour la première fois, je l'ai désinstallé.

C'est ainsi que fonctionne l'être humain : il s'adapte à quelque-chose, et ne veut plus en changer. Ce phénomène est encore accentué dans l'informatique car les notions sont bien plus complexes. Passer d'un stylo à un bic est embêtant, mais on s'y fait vite. Passer de Windows à Linux prend des mois.

Tout refaire, tout repenser

Ce que j'admire dans le projet KDE est de se baser sur rien du tout (contrairement au troll velu disant que KDE copie Windows). Quand les développeurs ont conçu KDE 4, ils ne se sont pas dit «Comment ils font ?», mais bien «Comment ça devrait être fait». C'est d'ailleurs un mouvement à la mode, GNOME 3 reprenant la même idée.

Je vais commencer par KOffice. Alors que OpenOffice.org copie l'interface de MS Office, et que les autres suites de traitement de texte se ressemblent, KOffice est totalement différent, vraiment. Dans KOffice, on a de petits fenêtres dockables comme on souhaite, qu'on peut balader n'importe où. La différence «Tâche/Programme» est également floue. J'en reparlerai plus tard.

L'environnement de bureau KDE lui-même est assez bien différent aussi. Oui, il y a une barre en bas de l'écran, mais honnêtement, avant KDE 4 (ou 3.5, ça dépend d'où on commence), vous imaginiez mettre le menu K sur le bureau et supprimer le dock ? Ça vous disait quelque-chose d'avoir un client IRC sur votre écran de veille ? Oui, peut-être qu'un gestionnaire de fenêtre ou environnement quelconque faisait ça, mais ici, c'est du grand publique.

L'intégration est primordiale

C'est un fait reconnu, KDE aime intégrer. D'une part l'utilisateur aime bien (et j'expliquerai pourquoi), mais d'une autre part ça permet au programmeur de moins travailler.

KDevelop par exemple réutilise Kate pour afficher du texte, et propose une Konsole pour lancer des commandes. Konqueror peut afficher un aperçu de textes dans Kate, Kate peut contenir une Konsole, etc. Ainsi, où qu'il soit, l'utilisateur pourra voir un fichier de texte, ou lancer des commandes. Il aime. Le développeur, quant à lui, n'a pas besoin de recoder un éditeur de texte ou un émulateur de terminal.

Imaginez que vous vous baladez dans un dossier, on va dire ~/Documents. Soudain, vous voyez un magnifique fichier .odt. Vous souhaitez l'ouvrir pour vite changer quelque-chose dedans, et vous utilisez Konqueror. Clic droit»Aperçu avec...»Composant KWord. Voilà, vous avez une fenêtre KWord intégrée dans Konqueror, partageant ses barres d'outils. Vous pouvez faire avec ce fichier tout ce que vous faites avec KWord, vous pouvez également utiliser Konqueror comme avant. Vous pouvez par exemple bookmarker votre fichier !

Cette intégration dans KDE est formidable et permet vraiment de travailler très vite. Mon exemple est tordu, mais imaginez qu'une moule sur Linuxfr vous donne un lien vers un fichier .odt. Vous n'avez pas envie de le télécharger, de trouver où le mettre, d'ouvrir votre gestionnaire de fichiers, de cliquer dessus, de charger un programme. Non, là aussi, Clic droit»Aperçu avec le composant KWord vous l'affiche dans Konqueror. Si vous faites un clic-droit»Ouvrir dans un nouvel onglet, le composant KWord sera automatiquement utilisé.

Pas besoin d'ouvrir des fenêtres, c'est rapide et efficace.

Du côté de KOffice maintenant, où on remarque encore une fois cette magnifique signature du projet KDE. Je démarre Krita, l'éditeur d'images. Je dessine tranquillement, puis veut intégrer un texte. Je clique sur le bouton qui va bien, et tape mon texte ... dans KWord ! Non, une fenêtre ne s'est pas réouverte. Simplement, quand j'édite ma zone de texte, les barres d'outils et les fenêtres dockables changeant et s'adaptent au mode d'édition de texte. Je peux mettre des styles, de la mise en forme, insérer des graphiques, et tout ce que je fais avec un traitement de texte ... dans une image.

Prenons KWord, et insérons-y une image. Si je clique dessus, opération inverse, je me retrouve avec une interface «Kritarienne». Si j'avais insérer une feuille de calcul, j'aurais également pu la modifier, la scripter, etc.

KDE a la réputation d'usine à gaz ne respectant pas la philosophie UNIX, mais en fait si, il la respecte et est même l'exemple. Aucune application graphique ne la respecte mieux. L'éditeur de texte est un éditeur, il ne fait que ça, mais il le fait bien. Konqueror est un shell, qui peut «lancer» (c'est à dire incorporer) l'éditeur de texte, comme il peut incorporer KWord, Okular et tout un tas de programmes.

Donc non, Konqueror n'est pas un couteau suisse lourdinge, c'est un puissant shell graphique permettant d'assembler des composants entre eux. L'atout d'UNIX était le pipe, permettant de relier des commandes («cat fichier | grep truc | wc -l»). Konqueror permet également de lier les composants entre eux (aller sur un site, ouvrir un lien vers un .odt dans un nouvel onglet, afficher le fichier .pdf qu'il contient dans Okular, enregistrer une page comme image, la traiter dans Krita, y incorporer du texte et des graphiques, et mettre le tout dans une feuille de calcul, imprimée par la suite).

Pourquoi j'aime l'environnement (Plasma, etc)

Il existe plusieurs types d'utilisateurs. La «Madame Michu» et le geek, ainsi que tous ceux entre ces deux extrêmes. Madame Michu n'aime pas configurer, veut que ça «juste-marche». Le geek par contre veut que tout se comporte exactement comme il veut.

Quand on démarre KDE pour la première fois, l'environnement fonctionne et est prêt à être utilisé. Tous les mécanismes d'intégration marchent. C'est valable également pour la version SVN, donc c'est indépendant de la distribution. La Madame Michu est comblée, elle peut directement lancer son traitement de texte, son navigateur web, etc.

Plasma entre ensuite en jeu. Si le geek aime l'interface de GNOME, pas de problèmes. On met un deuxième dock en haut, on les rétrécis, on déplace/ajoute/supprime des widgets à tout vas, et on arrive à avoir un truc qui ressemble et se comporte comme GNOME.

Si le geek n'aime pas le menu K, il peut le changer. Le menu classique est très clair et très efficace. Il existe aussi le méconnu Lancelot, un peu difficile à appréhender (il faut dire qu'il est plus que complet), mais dont on ne sait plus se passer.

Ensuite, on peut peupler le bureau, y placer des widgets, y afficher la météo, une page web, des fichiers, etc. On peut le faire se comporter comme un fond d'écran, un diaporama, une fenêtre sur l'extérieur (en fonction de la météo, il affiche des photos différentes), un script, des fractals, un globe terrestre, et, depuis KDE 4.4, un magnifique shell affichant, à la place des icônes, les catégories disponibles. Quand on clique par exemple sur «Internet», ça affiche le contenu de cette catégorie. Ça mérite un screenshot tellement c'est bien pensé.

Bref, plasma est très souple et permet de faire tout ce qu'on veut de lui. Il propose plein de fonctionnalité dont on ne sait plus se passer ensuite (rien que par exemple Alt+F2 qui permet de faire des calculs, ou alors Lancelot qui m'affiche mes mails non-lu (intégration KDE inside)).

Petit exemple au passage : quand je tape un texte, j'appuie souvent sur Control+S pour l'enregistrer. Il m'est arrivé plusieurs fois d'appuyer sans le vouloir sur Control+Q, et d'avoir une boîte de dialogue qui gêne mon travail. Dans le menu configuration, on peut changer les raccourcis clavier. J'ai supprimé Control+Q, je suis tranquille. Ça existe dans toutes les applications KDE !

Pourquoi j'aime KOffice

Du côté de KOffice, c'est clairement l'intégration que je préfère. Lancer une des applications de KOffice est en fait spécifier quel type principal de document on va gérer.

Si je veux taper du texte, contenant des images, j'utiliserai KWord. Si je veux créer une image, contenant du texte, c'est Krita que je vais utiliser. Si je veux que le tout soit dans une feuille de calcul, je peux lancer KSpread.

La paresse des développeurs est également excellente, comme dit plus haut. Chaque application peut gérer les fichiers de tous les autres, et l'interface est ingénieuse. Un truc que j'ai bien aimé, dans Krita, est l'outil de peinture. On sélectionne et configure son outil (par exemple un spray, un pinceau, etc), puis on l'utilise avec ce qu'on veut. Je peux tracer des cercles, rectangles, courbes, des lignes à la main, avec cet outil, sans devoir le reconfigurer à chaque fois.

Mon premier titre est «Oublier ce qu'on connaît», et c'est typiquement dans KOffice que ça s'applique. Si vous lancez KOffice en voulant l'utiliser comme MS Office ou OpenOffice.org, vous n'allez pas aimer.

Non, il faut faire le vide dans sa tête. Ensuite, pour chaque tâche, se dire «Comment je ferais ça si je ne connaissais rien à la bureautique». Les éléments se suivent et se trouvent là où on les attends, tout est particulièrement ergonomique.

Par exemple, j'ai tapé une ligne de texte dans KWord. Je veux que ce soit un titre. Non ! Pas penser «Mettre en gras, 32px, souligné». On va simplement dans la fenêtre dockable «style», on sélectionne «titre de document», on clique sur le bouton plus.

Pourquoi devoir cliquer sur ce plus ? C'est inergonomique ! Et bien non, c'est tout à fait logique. Un élément peut avoir plusieurs styles. Il peut par exemple être «mis en avant» et «titre», ou «titre de niveau 2» et «premier titre de la page» ou «titre d'un élément que les connaisseurs peuvent sauter». C'est comme en CSS, les styles s'appliquent les uns après les autres au texte.

Passer un document d'un style à un autre devient enfantin. Si on veut que tous les titres soient affichés en bleu, on change un paramètre. Les 1000 pages de document s'adapteront. Si on veut que les titres «peu importants» soient italiques et légèrement plus clairs, on change les options. Ils seront bleus, comme tous les titres, mais seront également en italique et légèrement plus clairs.

De même pour les autres programmes. Dans une feuille de calcul, je veux créer un graphique. Habitude de MS Office : chercher le bouton dans la barre d'outils. Méthode KOffice : glisser-déposer un élément de type «Graphique» depuis la fenêtre dockable «Éléments». Ensuite, cliquer dessus, et le modifier comme on veut (en y ajoutant des colonnes, en l'adaptant, etc).

Le tout est avancé technologiquement et beau

Avertissement : on entre dans le subjectif et le trollesque. Sortez le trollomètre !

En plus d'une belle intégration entre les composants, ces composants eux-même sont complets et très avancés technologiquements. N'oubliez pas une dépêche récente annonçant la sortie de «simon», un logiciel de reconnaissance vocale pour KDE qui permet de contrôler son bureau à la voix. KTTS permet l'inverse : lire l'interface.

Outre ces «gadgets de l'an 3000», il y a aussi des fonctions dont on oublie qu'elles sont avancées, comme par exemple le globe terrestre en fond d'écran (qu'on peut au passage bouger et zoomer avec la souris, oui oui, un papier peint interactif !). Les KIO, qui permettent à toute application KDE d'ouvrir tout fichier, sont très utiles.

Pas plus tard que ce matin, j'ai du récupérer le logo de Initng. Facile, je vais sur son site, clique droit sur la bannière, copie le lien, ouvre Krita, clique sur l'onglet «Ouvrir un document», et colle mon lien.

Oui, c'était du http, distant, sur un serveur inconnu. Néanmoins, Krita m'as ouvert l'image, que j'ai pu modifier. À l'enregistrement, il m'a gentiment proposé de l'enregistrer dans mon dossier d'images, ce que j'ai fait. J'ai ainsi pu récupérer en toute facilité une icône de 32x32 représentant le i dans un rond d'allumage, le logo de Init-ng.

J'ai un serveur dédié, sur lequel se trouvent pas mal de fichiers, dont des scripts PHP. J'ai un jour du en modifier rapidement un. J'ouvre mon fidèle Konqueror (ça marche aussi avec Dolphin), entre l'url «fish://steckdenis@logram-project.org/», tape mon mot de passe, et accède à mon dossier personnel. J'édite le fichier dans Kate (en cliquant dessus, comme si j'étais en local), clique sur le familier bouton «Enregistrer», et voilà. Je réactualise ma page, je vois que le changement est appliqué.

Retournons à Plasma. Une des nouveautés de la version 4.4 sera les widgets distants. Cela permettra de partager sur un réseau ses widgets. Je n'ai pas encore beaucoup d'informations là-dessus (je n'ai pas deux ordinateurs faisant tourner KDE 4.3.50 pour tester), mais il me semble que ça permettra d'afficher sur mon ordinateur un widget de notes, ainsi que sur celui de ma mère. Quand elle aura une question à poser, elle n'aura qu'à écrire dedans, moi à lui répondre. Oui, c'est comme un chat, mais ça s'applique à tous les widgets. Imaginez partager avec vos amis la chanson que vous écoutez, c'est possible, en passant par internet, avec ces widgets distants.

Un journal est passé aux alentours du début du mois avec comme sujet une nouvelle passée sur le dot de KDE montrant la liste des projets du Google Summer of Code et leur état. Une trentaine de projets ont été présentés, dont pas mal d'intéressants.

Celui qui m'a le plus supris est un système de filtres pour Akonadi, donc KMail. Il permet d'exécuter plein d'actions en fonction d'un mail, comme par exemple «Si ce mail vient de mon patron, l'enregistrer dans le dossier "travail" et jouer un son. Afficher également une notification». Ça existe peut-être dans d'autres clients mails, mais avec Akonadi, ce qui est excellent, c'est que ça marchera même si le client mail est éteint.

En effet, Akonadi est une de ces technologies que j'aime : totalement différente et nouvelle, particulièrement utile. C'est un serveur d'informations personnelles. Il est lancé en même temps que KDE, et s'occupe de relever le courrier, de surveiller vos contacts Jabber, de récupérer vos flux RSS, etc. Il existe ensuite des applications client, accédant à ses informations. N'importe quelle application (dont le menu Lancelot) peut demander la liste des mails qui sont arrivés, afficher les contacts en ligne, lister des contacts, etc. De plus, la synchronisation est assurée. Si je modifie un contact dans KMail, il sera mis à jour instantanément dans KAddressBook.

Conclusion

Ce journal n'a pas pour but de lancer un troll, c'est juste un énorme retour d'expérience d'un utilisateur heureux de KDE 4, depuis plus d'un an. Je l'ai vu évoluer, et l'apprécie de plus en plus. C'est vraiment un environnement de bureau d'exception, étendard du Libre, permettant, si correctement présenté, de faire venir beaucoup de monde sous Linux (car sous Windows, KDE n'est plus vraiment KDE).

C'est également un plaisir d'avoir son ordinateur sous ses ordres, au lieu d'être sous les ordres de son ordinateur. KDE est également un solide rock qui permettra, si trop de gens hurlent que Windows 7 déchire tout, de leur dire «Oui, mais regardez comme ceci est largement mieux». Ils ne vont peut-être pas venir, mais ils vont au moins se calmer.

Sinon, KDE s'utilise rapidement, et est très efficace. Il faut juste prendre le temps de le découvrir, lui laisser sa chance. Ce n'est pas parce qu'un bouton n'est pas là où il devrait que KDE est nul. Un exemple personnel : je voulais changer la couleur des décorations de fenêtres, parce que j'en avais marre du blanc. J'ai cherché, mais pas trouvé. Je me rappelais alors combien c'était simple sous Vista (Apparence»Fenêtres, c'est à peu près le seul truc qu'on peut changer). Un jour, j'ai réessayé, en me disant «Si j'étais logique, où j'aurais mis ça». Je vais dans Apparence, puis dans Couleurs, changer les couleurs, je sélectionne «Couleur des décorations de fenêtres», change, ça marche. Brillant exemple qu'il faut vraiment se fier à l'ergonomie du machin, pas à ce qu'on sait déjà.

Voilà, vous avez mon avis. Vivement KDE 4.4 qu'on puisse bien tester tout ça, mais la version 4.3 est déjà largement plus qu'utilisable (je l'utilise). Je vous encourage en particulier à prendre une trentaine de minutes pour tester KOffice, ça vaut vraiment le détour de voir ce qui se fait ailleurs. Ça vous fera comme la première fois où vous avez testé Linux, en ayant connu Windows ou Mac OS.

> Lire le journal (111 commentaires, moyenne: 3,1).

Bonjour,

Récemment, une dépêche est sortie pour annoncer les gagnants des livres, et je fus cité pour mon journal LLVM dans un gestionnaire de paquets ?. Je remercie encore une fois toute l'équipe de Linuxfr pour m'avoir désigné.

Petit rappel : LLVM, pour Low-Level Virtual Machine, est une "machine virtuelle" capable de compilation «Juste-à-temps» d'un pseudo-code généré par des compilateurs spéciaux. Dans mon journal, je proposais d'utiliser LLVM pour empaqueter des applications en prenant moins de place, indépendant de l'architecture, et surtout pour qu'une dernière phase de très forte optimisation soit faite du côté client. Clang est un compilateur C et C++ capable de sortir du pseudo-code LLVM, et est conçu pour être utilisé avec LLVM.

À l'époque, c'est à dire il y a deux mois, j'avais mis le projet en attente car, bien que le support du C par Clang soit très bon, celui du C++ était encore très très mauvais.

Aujourd'hui, par curiosité, je décide de me rendre à nouveau sur la page Clang C++ Support. Je ne me souviens plus très bien de comment elle était la dernière fois que je l'ai vue, il y a deux mois. La seule chose que me rappelle était son état désolant : «Au début, c'est vert. Puis le reste est orange, puis blancs et le reste est rouge. Plein de blanc, plein de rouge, quasi rien de supporté».

Je retourne donc sur cette page, m'attendant à retrouver cette marrée de rouge et de blanc. Je défile donc : «Le vert, comme d'habitude, la petite zone blanche comme avant, le gros bloc de vert qui fait plaisir à voir, encore du vert, ah tiens, un peu de orange, mais plein de vert encore, une zone vert foncé (donc presque supporté), un peu de vert, une petite zone rouge, une zone modérée de blanc, puis les spécifications C++0x».

Vous voyez la différence ? Dommage que je n'ai pas de sauvegarde, mais je suis quasiment certain que la quantité de vert a quadruplé, et que plein de blanc a été remplacé par du vert, ou du orange. Il n'y a quasiment plus de rouge, et juste une dernière zone de blanc.

Je n'ai pas encore testé (ce machin prend quand-même deux jours à compiler sur mon petit Atom), mais je vais le faire très bientôt. Le jour où Clang-LLVM me compilent Qt sans erreur, c'est ok, je l'intègre à mon gestionnaire de paquets ! Surtout que Clang est nettement plus rapide que GCC, donc je pourrai enfin compiler tout KDE plusieurs fois par jour, au lieu de devoir réserver une semaine complète.

Chapeau donc à l'équipe de développement de Clang. Ils ont mangé du lion, j'en suis presque certain. Ou alors, ils ont reçu l'aide de plein de gens. Ces temps-ci, je félicite beaucoup les développeurs du Libre, et avec la dépêche sur Xorg, je vais encore le faire.

Serait-on dans une période particulièrement faste, ou alors c'est moi ? C'est toujours comme ça, après un GSoC ?

C'était le journal qui ne sert à rien du mercredi ©®

> Lire le journal (4 commentaires, moyenne: 4).

Bonjour,

D'Humeur à faire des tests, et bénéficiant depuis peu d'une connexion 30Mbps limitée à 30Gio/mois, je me suis mis en tête de télécharger la dernière bêta de Mandriva 2010.0 et de l'installer, histoire de tester et de découvrir Mandriva.

En effet, comme dit dans un de mes précédents journaux, j'ai trouvé la version 2009.1 de Mandriva exceptionnellement supérieure aux autres distributions, de mon point du vue.

Je télécharge, écrit tout ça sur ma clef USB, et démarre dessus. Cette fois-ci, tout marche impeccablement. Je lance l'installateur, partitionne (cette fois-ci, c'est une partition Ubuntu 9.04 qui a valsé :-) ), configure, et installe.

Au redémarrage, écran noir avec une boîte blanche au centre. Pas de panique, Ctrl+Alt+F1, et j'arrive dans une console virtuelle qui marche. Au passage, je remarque les joies du KMS : le switch est instantané, sans devoir changer le mode de mon écran :D ! Je lance un top, et voir qu'un grep utilise 11% de ma mémoire et 100% de mon IO. Je repasse en graphique, qui s'est curieusement débloqué. Je m'inscrit alors sur leur site comme c'est si gentiment proposé.

Ensuite, le bureau démarre, toujours avec le grep en arrière-plan. Le tout est réactif, le défilement de l'utilitaire de présentation est fluide, la 3D marche (carte Intel + pilote libre), parfait.

Je clique sur le menu K, et arrive, au bout de 5 secondes, sur leur petit menu de KDE3. C'est là que je remarque un bug bien embêtant que j'avais connu du temps de la sortie de KUbuntu 9.04 : le pilote Intel semble lent, très lent. Une fois que les composants sont affichés à l'écran, ça va, mais la création de fenêtre est d'une lenteur désolante. J'ai testé l'ancien menu, le nouveau, et Lancelot, avec et sans composition, c'est toujours aussi lent. Ouvrir une boîte de dialogue est également poussif.

Je me dis qu'une mise à jour va corriger le problème. Magnifique, une jolie icône en forme de point d'exclamation s'est affichée. Ca change de mon temps sous Debian Sid, qui n'affiche pas cette icône. Je coche toutes les mises à jour, et remarque que ça va m'installer 800 paquets. Pas de panique, j'ai une connexion de monstre maintenant, donc j'appuie sur OK.

Je n'aurais pas du. 2 heures, oui, deux heures que ça a pris !! Je n'ai jamais vu un truc aussi lamentablement et ignoblement poussif. Je savais que comparé au .deb, le RPM n'était pas rapide, et que les outils Mandriva sont codées en perl, mais là, c'est clairement le programmeur qui a bu.

J'ai 800 paquets à installer. Ça m'en télécharge 8, puis ça vérifie les signatures (et bien entendu, ça ne télécharge rien de plus, sinon ce serait trop beau), puis ça les installe un par un par un RPM poussif qui prend 5 secondes par paquet. Une fois le groupe fini, on télécharge les 8 paquets suivant, vérifie, installe, etc. Ce petit manège a duré des heures, pour finalement bien se terminer (en prenant tellement son temps, c'est impossible de rater).

Quand je pense que pendant ce temps-là, je développe un gestionnaire de paquets capable de télécharger, décompresser et installer en parallèle, je me dis que j'ai bien fait, tellement la fonctionnalité manque quand on ne l'as plus. Bon, par contre, la résolution des dépendances est rapide, plus que APT/Aptitude (Aptitude est plus lent que APT), ça a du prendre une demi seconde pour la mise à jour de 800 paquets.

Bon, une fois ces paquets installés, je découvre les magnifiques outils de configuration de Mandriva. Là encore, c'est beau, c'est fluide, et on a le choix. Ce truc, je suis certain qu'il sait faire le café si on trouve le bon bouton ! Je trouve l'endroit où on installe les paquets, sélectionne «Tout» à la place de «Uniquement les applications graphiques» (très bon ce filtre, ce sera repris dans ma GUI), et recherche "libqt4-dev". J'installe libqt4-devel, puis kdelibs4-devel (qui m'installe 300 autres paquets, dont cups-common o_O), et installe.

Là aussi, ça prend son temps. J'en profite pour aller lire mes mails, c'est à dire configurer Kontact. Ce doué d'installateur, à qui j'avais bien dit que j'ai une partition /home, l'a bien monté comme il faut mais a écrasé mon dossier de mails dans KMail pour aller mettre ce petit mail de présentation de Mandriva pour m'accueillir. Pof, a plus les 150 mails que je gardait, et les 8000 autres dans la corbeille.

Il y a aussi d'autres petits machins qui ne vont pas, en particulier les paquets. En quoi ais-je besoin de gnome-common ? Toujours ces foutues applications qui dépendent de GNOME alors qu'elles ne devraient pas, et Mandriva qui m'installe Ekiga alors que je n'ai rien demandé. J'ose à peine imaginer le nombre de trucs qu'on aurait pu faire rentrer sur le LiveCD si on n'avait pas la moitié de GNOME qui vient avec (au hasard, GIMP).

Du côté système, Mandriva est très bon. Il y a ce KMS qui marche bien, et la chaîne de démarrage qui est magnifique. GRUB 1 graphique (ça j'aime pas trop, trop hackish pour moi, j'aurais préféré GRUB 2), Plymouth qui marche à merveille, et des thèmes spéciaux pour KDM et KSplash. Le tout démarre très vite, et en 20 secondes, on est sur le bureau. Par contre, ils ont joué le Windows là. En 20 secondes, je suis sur le bureau, le disque à l'arrêt. Je me dis «Tiens, mes applications que j'avais lancées ne sont pas réouvertes, je vais les relancer». J'ouvre donc un Konqueror, et une Konsole s'ouvre ! Et oui, le démarrage des services (dont la restauration de session) est fait quelques secondes après le login. Ce n'est donc qu'une impression de bureau prêt, même si c'est vrai que c'est agréable d'avoir la main très tôt.

En clair, j'aime bien Mandriva. Quand on est resté sur une Debian Sid pendant plus de deux mois, c'est agréable de toucher à nouveau à une distribution pour débutant. Je vais pouvoir me concentrer sur mon code (en plus GCC 4.4 est installé à la place du vieux 4.3 de Debian), et le système se gère tout seul. Il suffit de faire les mises à jour, et ça roule. Le gestionnaire de paquets graphique avec les applis classées par catégories est super. On n'y pense pas, mais c'est très agréable quand on s'ennuie d'explorer la catégorie Jeux et d'en installer un au hasard. Qui sait, peut-être qu'un jour je contribuerai à un des jeux répertoriés là-dedans.

Une dernière note pour les versions : au menu, noyau 2.6.31.4 (alors que l'officiel est encore le .3, ils sont trop forts chez Mandriva), le pilote Intel 2.9.0 (donc le dernier), KDE 4.3.2 (donc le dernier), et tout un tas d'autres softs (dont FireFox 3.5, et ses dépendances GNOME 2.28).

Moi, je signe. J'ai peut-être dit un peu beaucoup de mal du gestionnaire de paquets, mais je l'aime bien. En quelques clics, on a le Logiciel Libre à sa portée.

Franchement, chapeau aux développeurs de Mandriva. C'est la distribution qui devrait être à la place d'Ubuntu.

> Lire le journal (52 commentaires, moyenne: 2,2).

Bonjour,

Hier, j'ai eu envie de compiler et de tester le noyau Linux en version 2.6.31. Je regarde donc dans les dépôts de ma distribution, et découvre qu'il n'y est pas.

Tant pis, je me dis donc que je vais le compiler moi-même. Je récupère les sources, configure (en laissant la majorité des choix par défaut, ce qui compile beaucoup, mais ce n'est pas grave), et compile.

Une fois le noyau installé, je redémarre dessus. C'est d'abord un échec (pas de son, pas de souris USB, pas de composition). J'essaie de me débrouiller avec le clavier, et ajoute les modules nécessaires (en fait il faut simplement compiler USB en built-in pour la souris USB, compiler ALSA en built-in pour le son, et la composition, je ne sais pas, ça a marché miraculeusement).

Je recompile et réinstalle tout ça, je redémarre, et je peux enfin tester.

J'en suis encore étonné ! Jamais je n'ai vu mon système aussi rapide. Oui, on m'a dit que le noyau Debian est optimisé pour les serveurs, oui j'ai configuré le mien aux petits oignons, oui il paraît que la couche des pilotes en mode bloc a été largement améliorée, mais passer d'un KDE qui démarre en 2 minutes à un KDE qui démarre en 40 secondes (chargement de la session compris), ça, je ne le savais absolument pas !

C'est sur la même partition, le même matériel, la même libc, la même distribs, etc. Tout le démarrage est plus rapide et plus fluide (les services démarrent vraiment en parallèle, alors qu'avec le kernel Debian, on voit qu'ils s'attendent encore un peu). Tout ce qui est accès concurrent est largement meilleur (démarrage de Amarok + Konqueror + Kmail + Konsole (avec 8 onglets, donc 8 bash) et sous les services de KDE largement plus rapide).

J'ai également vu passer qu'une belle amélioration avait été ajoutée dans ext3 (que j'utilise encore sur mon /, merci Debian). Cette amélioration consistait à éviter des lourdeurs avec les ACL et tout un tas d'autre chose, ce qui rend le système de fichiers ext3 largement plus léger pour le CPU. J'ai justement un petit disque dur super rapide, et un CPU super lent (1,6Ghz, c'est peu par rapport au DD qui peut fournir 110Mio/s). Résultat : au démarrage de KDE, au lieu d'avoir mon CPU à 100% et le disque dur qui attend, le CPU est à 100% et le disque dur va au maximum.

Bref, j'ai toujours cru que toutes ces améliorations du noyau ne touchaient que très peu le desktop (quand on parle de la réduction d'une latence de 0,5ns, ça nous passe par dessus la tête), mais en fait pas du tout. Les moindres gains dans le noyau se répercutent directement sur le bureau, car le moindre goulet d'étranglement est utilisé des millions de fois.

J'ai donc maintenant un système réactif comme jamais, la composition qui marche, le KMS que je dois encore trouver comment activer, tout mon matériel détecté et qui marche, du son, ma souris, ma carte réseau, mon chipset, etc.

En clair, je suis heureux ! Merci aux développeurs du noyau pour nous fournir un travail d'une telle qualité.

> Lire le journal (40 commentaires, moyenne: 3,4).

Bonjour,

À qui n'est-ce pas arrivé, quand on présente des fonctionnalités avancées aussi abstraites que des «snapshots inscriptibles dans Btrfs», de se demande à qui ça pourrait servir ?

En effet, quand on entend ce genre de choses, on a tendance à dire que ça ne servira que dans des fermes de serveurs virtualisés, ou je ne sais quoi.

Petit rappel : Btrfs est un nouveau système de fichier pour le noyau Linux, encore en développement. Outre sa manière bien spéciale de stocker les fichiers sur le disque (sous forme de B-tree), il permet également tout un tas de fonctionnalités toutes plus farfelues les unes que les autres, comme le redimensionnement à chaud, la défragmentation à chaud, les snapshots, etc.

Un snapshot est une image de l'état dans lequel se trouve le système de fichier à un instant T. On peut le voir comme une révision dans les systèmes de contrôle de révisions. Par exemple, imaginez que vous avez un certain système de fichiers, et que vous allez y apporter des modifications. Pour ne pas perdre de données, vous allez créer un snapshot contenant l'état actuel, et le supprimer si tout s'est bien passé.

C'est justement ce fonctionnement qui m'a donné une idée d'application dans la vie de tous les jours de ces snapshots inscriptibles :

Madame Michu découvre la console. Elle n'est pas du tout à l'aise, et suit un tutoriel trouvé quelque-part. Elle n'a vraiment pas confiance. Pour travailler en sécurité, elle commence par taper la commande "snapshot", par exemple. Cette commande, un script shell, crée un nouveau snapshot (éventuellement nommé suivant la date et l'heure, et enregistré quelque-part).

Ensuite, elle fait ses modifications. Une fois les modifications terminées, soit tout a bien marché, et elle tape "apply", soit quelque-chose a mal tourné, et elle tape "revert".

Madame Michu est donc contente, car elle peut faire ce qu'elle veut, y compris un "rm -rf /" (bon, peut-être pas, /usr/bin/revert doit exister, sauf si c'est une commande interne de son shell), si quelque-chose tourne mal, un simple revert lui remettra son système de fichier exactement comme il était.

Un autre cas : Monsieur Michu (qui a entre temps pu avoir accès à l'ordinateur) décide d'installer un paquet. Son gestionnaire de paquets, en toute transparence, lui crée un snapshot. Ensuite, il installe les paquets. Si quelque-chose tourne mal, et que le système a été touché, un revert suffira à le remettre d'aplomb. Si tout va bien, on continue.

Autre cas, la fameuse «restauration système» de Windows. Monsieur Michu va installer une application en la compilation lui-même, pour la première fois. Il est un peu plus frileux que Madame Michu, et donc suit scrupuleusement la documentation, qui ne précise pas la suite «snapshot, revert». Par contre, prudent, il va dans la GUI «Restauration du système», et crée un nouveau point de restauration. Il peut alors s'amuser comme il veut, modifier tout son système, puis finalement restaurer son point si quelque-chose a mal tourné. Remarquez que l'application de restauration étant en RAM, un "rm -rf /" peut être contré !

Encore un autre cas ! Madame Michu, qui s'est battue avec son mari pour récupérer l'ordinateur (avant qu'il ne soit totalement foutu), décide de modifier un document OpenDocument pour son travail. Elle sait qu'elle va y apporter de grosses modifications, et n'a pas envie d'en créer des copies. Clic droit»Propriétés»Historique»Créer un point de sauvegarde, et le voilà placé dans son "petit snapshot" (note: il faut voir si c'est possible de versionner tout un fichier et pas seulement un disque entier, pour permettre de restaurer les fichiers un à un).

Elle modifie ensuite son fichier, puis l'enregistre. Elle peut faire ça plusieurs fois, l'onglet «Historique» lui affiche toutes les versions, c'est parfait. Si un jour elle fait une bêtise, un simple revert lui rendra le sourire.

Voilà, ceci est la liste de tout ce qu'on peut imaginer avec ce magnifique Btrfs. Inutile maintenant de vous dire que ce sera le système de fichiers par défaut de Logram, une fois sorti (mais à mon avis, Logram sortira après Btrfs).

Petits points intéressants :

• Btrfs est censé capturer des snapshots instantanément
• Dans mes exemples, les snapshots ne doivent pas être inscriptibles. On pourrait tourner ça de la sorte : créer le snapshot » passer dedans » écrire dedans » le garder ou le jeter
• Il faut voir s'il est facile de passer un snapshot comme étant la «racine du système de fichier», c'est à dire ce que fait la commande «apply». Btrfs étant en développement, on pourrait le demander à ses développeurs

Voilà, j'attends vos avis. Avez-vous d'autres idées ? Trouvez-vous ceci intéressant ? Est-ce possible techniquement (maintenant ou plus tard) ?

> Lire le journal (92 commentaires, moyenne: 3,2).

Bonjour,

Aujourd'hui, je vais vous parler de ce que j'ai codé cet après-midi, mais surtout de ce que j'ai pensé depuis maintenant un peu plus d'un mois.

Sous Linux, nous bénéficions généralement d'un système de gestion des paquets, assez performant. Un des problèmes que chacun de ces gestionnaires doit vaincre est la gestion des dépendances.

En effet, des paquets peuvent ne pas vouloir s'installer en compagnie d'autres, ou peuvent en nécessiter. Tout ceci peut vite devenir très complexe, quand un système de dépôt, de versions multiples, etc, sont mis en jeu.

Nous avons actuellement deux solveurs de dépendances qui sont fort connus, et quelques autres. Un des plus utilisé est APT (Advanced Packaging Tool) de Debian, qui résoud très bien tout un tas de dépendances très complexes, et ce très rapidement. C'en est presque devenu une référence. Un autre est Zypp, utilisé par OpenSuSE. Il a ouvert la voie à tous les autres en étant le premier à utiliser un algorithme de satisfaction booléenne. Nous pouvons également citer Yum de Fedora, et URPMI de Mandriva.

Après ces solveurs, il y a les "incomplets", c'est à dire ceux qui marchent mais ne permettent pas de gérer tous les cas. Nous avons Portage chez Gentoo qui ne permet pas de gérer les reverse-dependencies (donc si vous supprimez une bibliothèque, tous les programmes qui en dépendent restent, cassés), ainsi que Pacman de Arch Linux, qui semble également ne pas gérer les dépendances inverses. Il y a aussi les gestionnaires de paquets de distributions comme Slackware. Les autres, je ne les connais pas assez.

Après cette longue introduction, venons-en au fait : j'ai créé un solveur de dépendances assez intéressant :

• Il est complet à tous points : les reverse-dependencies sont gérées, les provides le seront également bientôt, et il trouve toutes les possibilités, et est capable de les présenter à l'utilisateur
• Il est extrêmement rapide : il ne fait jouer que les paquets nécessaires. Par exemple, le solveur SAT de OpenSuSE et APT nécessitent de lire toute la base de donnée des paquets, tandis que mon solveur ne charge que les paquets qui sont des dépendances, conflits, dépendances inverses, suggestions, remplaçants, etc
• Il est incroyablement simple : solver.cpp ne fait que 235 lignes !

Il utilise un concept assez intéressant, ou plutôt plusieurs :

• Une base de donnée "à la OpenSuSE", c'est à dire binaire, gérée par le solveur lui-même, et partant de principe qu'il faut éviter tous les for() (instructions de boucle qui rendent rapidement un programme très lent quand il a des millions d'entrées). Trouver les dépendances d'un paquet n'a que la complexité O(nombre de dépendances), et non O(nombre de paquets de la BDD) comme chez les autres. Trouver toutes les informations d'un paquet est en temps constant, trouver les versions d'un nom de paquet est O(nombre de versions), etc. C'est difficile à gérer (et à construire, je prend pour preuve databasewriter.cpp qui pèse 727 lignes), mais c'est foudroyant à l'utilisation
• Setup, le gestionnaire de paquets autour, a une particularité assez intéressante : il est très user-friendly (bien que seulement en console pour le moment) : sortie colorée, absolument toutes les chaînes sont traduites (y compris le titre, la description courte et la description longue d'un paquet)
• Logrammien. Ce système a été développé en premier lieu pour Logram, mon projet de distribution utilisant comme environnement de bureau KDE et son propre mini-environnement de bureau. Logram sera le plus user-friendly possible, et toutes les touches sont apportées (dont un système de paquet internationalisé et rapide, une intégration des outils à KDE, etc)
• Le solveur lui-même (pour revenir au sujet) utilise un système de branches, que je détaille maintenant

L'idée m'est venue en utilisant des systèmes de contrôles de versions (VCS). On peut aisément créer une branche, travailler dedans, et la supprimer si ça ne va pas. J'ai simplement appliqué ce principe aux gestionnaires de paquets, et ça a l'air de bien marcher.

Le principe est simple : au début de la résolution, on crée une branche (la branche principale). Dans cette branche, on place le paquet qu'on veut installer.

Ensuite, on explore ses dépendances. S'il n'y a pas de "choix", donc qu'on dépend par exemple de libqt4-gui et qu'il n'existe qu'une seule version de cette bibliothèque dans les dépôts, on la prend. S'il y a plusieurs choix possibles (ici plusieurs versions), on crée une branche par choix.

Ainsi, les branches divergent, et si quelque-chose n'est pas possible (conflit insoluble), on élimine la branche. A la fin de la résolution, devenue "bête et méchante" (c'est à dire qu'on installe les dépendances, supprime les conflits, etc sans se soucier du reste), on obtiens la liste des branches possibles.

Reste alors à les "peser", c'est à dire à obtenir un score pour chacune d'elle, en fonction de critères divers (nombre de paquets à installer/supprimer, mises à jour, taille à télécharger, etc). La branche la plus lourde est présentée à l'utilisateur, c'est potentiellement la meilleure. Les autres sont gardées, pour permettre à l'utilisateur de cliquer sur un bouton «Autre possibilité» si la solution présentée lui désinstalle son paquet de-la-mort-qui-tue qu'il veut garder.

Le résultat est élégant, et Qt aide (oui, c'est développé avec Qt). Le code est court, et marche. Il n'est pas encore assez propre, pas encore fini, mais est disponible sur le SVN de Logram à l'adresse svn://logram-project.org/logram/trunk/Distro/libs/libpackage (architecture bibliothèque/client powa :) ). Le client console est là : svn://logram-project.org/logram/trunk/Distro/base/setup .

Pour le moment, cette bibliothèque et son client ne savent pas installer de paquets. C'est une affaire de semaines, la partie "difficile" étant faite (encore quelques détails à régler avec les provides et la liste des paquets installés, et c'est bon). Toute la partie création de paquets, mise sur le serveur et gestion des miroirs est faite.

Exemple concret

Mes explications sur l'architecture par branches ne me semblent pas assez claire. Je vais vous montrer un exemple, avec le dépôt contenant les paquet suivants :

• initng-plugins, qui dépend de initng >= 0.6.0
• initng en version 0.6.0
• initng en version 0.6.99-gitAug3009, dépendant de libinitng == 0.6.99-gitAug3009
• libinitng en version 0.6.99-gitAug3009

Je veux donc installer initng-plugins, donc je lance :

setup add initng-plugins

(note: pourquoi add ? Parce que install ne va pas, car si on préfixe le nom d'un paquet par "-", on le désinstalle, ce qui est plus pratique : setup add initng-plugins -libinitng-dev)

Voici simplement les étapes qui sont exécutées par le solveur :

• Créer la branche master, et y placer initng-plugins
• initng-plugins dépend de deux version (0.6.0 ou 0.6.99-gitAug3009) de initng
• Création d'une branche, dans laquelle on place initng-0.6.0
• initng-0.6.0 ne dépend plus de rien, on retourne true :)
• Dans la branche principale (oui, on recycle), on ajoute initng-0.6.99-gitAug3009
• initng-0.6.99-gitAug3009 dépend de libinitng-0.6.99-gitAug3009. On l'ajoute dans cette branche
• Il n'y a plus de dépendances, on peut retourner true :)

C'est un exemple simplissime, mais qui montre comment les branches permettent de facilement se tirer du problème dans devoir sortir une artillerie telle que SAT. Au final, on a deux branches, contenant respectivement :

• initng-plugins, initng-0.6.99-gitAug3009 et libinitng-0.6.99-gitAug3009
• initng-plugins, initng-0.6.0

On les pèse, et en fonction de ce que l'utilisateur veut (du bleeding endge ou du stable), on installera la première ou la deuxième.

Voilà, le journal du vendredi qui ne trolle pas trop. J'espère que je ne fais pas fausse route, mais chez moi, avec un dépôt un peu plus complexe, ça marche :

$ ./setup add initng-plugins
{
"initng-plugins" "0.6.99+gitAug302009~1"
"initng" "0.6.99+gitAug302009~1"
"libinitng" "0.6.99+gitAug302009~1"
}
{
"initng-plugins" "0.6.99+gitAug302009~1"
"initng" "0.6.98"
"libinitng" "0.6.99+gitAug302009~1"
}
{
"initng-plugins" "0.6.98"
"initng" "0.6.99+gitAug302009~1"
"libinitng" "0.6.99+gitAug302009~1"
}

PS: Oui, dans mon résultat, les *-0.6.98 dépendent des version Git, c'est normal, j'avais la flemme de changer la version des dépendances :-° (surtout que comme c'est maintenant, ça induit un petit stress en plus du côté des reverse-dependencies, donc on va pouvoir s'amuser :) )

> Lire le journal (44 commentaires, moyenne: 3,3).

Bonjour,

Dans ce journal, je vais vous parler de Mandriva, que j'ai re-découvert il y a quelques jours, et qui m'a laissé une très bonne impression.

Avant de commencer, sachez que la dernière Mandriva que j'ai testé était la 2007.1 (ça remonte), et que c'était aussi la première fois que je touchais du Linux. Je n'avais pas encore internet (tout ça pour dire : j'ai été dégoûté de Mandriva pendant bien 2 ans :P )

Parlons d'abord de cette 2007.1. Venant tout droit de Windows, j'ai été agréablement surpris par le monde Linux à cette époque. Un Windowsien est quand-même facilement surpris. Je me souvient avoir appelé mon père ... parce que le GRUB de Mandriva était graphique, avec une animation, et son bootsplash en mode verbose avait de la transparence, le tout en 24bpp : «Eh, viens voir, Linux est graphique même avant de démarrer». Voilà, c'est dit.

Il y a quelques jours, je décide de télécharger le LiveCD KDE de Mandriva 2009.1. Je préviens tout de suite, je n'ai pas eu de chance. Tout d'abord, pas moyen de trouver la version 64-bit, et je n'aime pas sous-utiliser mon ordinateur. Je prends finalement la version 32-bit.

Sachant que c'est du 32-bit, je peux tester sous VirtualBox. Je lance donc ce LiveCD sous VirtualBox, ça démarre :) . Première embuche : écran noir (tiens, la 2007.1 m'avait fait le même coup, moi et Mandriva...). Passage en VT1, kill de kdm, relancement depuis la ligne de commande, ça marche. Malheureusement, c'est inutilisable, je n'avais alloué que 384Mio de RAM à la machine virtuelle. J'éteins la machine, lui met 800Mio de RAM, et redémarre. Là, ça freeze au démarrage. J'éteins, et voit que j'avais activé l'accélération 3D. Je la désactive, démarre, ça marche.

Je décide donc de graver cette image sur un CD. Pour relancer les trolls : Debian n'aime pas Mandriva : K3B m'a gravé le CD en 24x au lieu de 12x, le CD était inutilisable. Heureusement, Mandriva à la pointe de la technologie me permet d'écrire cette image ISO sur un flashdisk USB. J'ai un flashdisk, qui contient un netboot Debian. La guerre continue ! Je supprime le netboot Debian et place l'iso Mandriva à la place (Debian, ma pardonnera-tu ?).

Je démarre ensuite sur la clef USB, et là ça devient intéressant :) !

Tout d'abord, le démarrage est foudroyant (bon, la clef USB n'est pas spécialement lente non-plus). En une dizaine de seconde, je suis passé du magnifique GRUB graphique à ... un écran de configuration.

On peut dire ce qu'on veut, Ubuntu est plus intelligent sur ce point. Le débutant qui essaie Mandriva pour la première fois, il ne sait pas quoi faire quand il tombe là-dessus («c'est quoi mon clavier, mon fuseau horaire (matériel ou logiciel), mes options, et cette licence ?»). Bref, je répond aux questions, et arrive sur un bureau KDE bien léché.

Et là, c'est le choc ! Je démarre Konqueror (je suis connecté en filiaire :) ), et remarque que Mandriva n'utilise pas le magnifique thème Oxygen. Oui, ce n'est plus trop lourd, et ce KDE a l'air de respirer, mais peut-être un peu trop, j'étais frigorifié à la fin : on est entouré de bleu pâle et de blanc, glagla. Par contre, ce Konqueror est extrêmement véloce (comme le démarrage), et beau. Je peux immédiatement aller mouler sur Linuxfr depuis ma Mandriva.

Je vois que Firefox est installé aussi (après m'être perdu dans leur menu old-school, on n'y pense jamais, mais c'est embêtant d'avoir un menu qui dégage quand par malheur la souris s'en écarte, je préfère le nouveau menu KDE). Second choc ! Ce Firefox est quasi exactement le même que Konqueror, ils utilisent le même thème graphique. Chapeau Mandriva, ce thème est joli, et est en plus le même pour GTK et Qt !

Lui aussi est rapide (ou alors c'est vraiment mon flashdisk, capable il faut le dire de rafales à 34Mio/s, temps d'accès de 2ns). Je continue l'exploration de ce menu (qui m'énerve), et découvre le centre de contrôle de Mandriva. C'est vraiment bien fait, dommage que ce ne soit pas intégré dans KSystemSettings (ben quoi, on a deux panneaux de configuration comme ils ont fait). Les outils sont très bons, un peu lents (quand on clique sur une icône, on peut aller prendre un café avant que la boîte de dialogue correspondante ne s'affiche), mais très bien pensés.

Je n'ai pas encore testé le processus d'installation (si c'est comme la 2007.1, on répond à des questions, puis on attend 2h devant des pubs pour le PowerPack :-° ), mais cette Mandriva me plaît. Je vais peut-être attendre la 2010.0 pour passer, le temps de m'habituer en LiveUSB à du RPM (ça fait 1 an et demi que j'utilise uniquement du Debian, avec un petit passage de 2 semaines sous Fedora, et quelques jours avec OpenSuSE).

Chapeau Mandriva, c'est tout ce que j'ai à dire. L'environnement est bien léché, bien empaqueté, la distrib a une belle identité, de beaux artworks, rien n'a planté pendant mes tests, tout était plus rapide que ce qu'on peut imaginer, et ce LiveCD de 700Mio contenait l'équivalent de 3CD d'Ubuntu (en gros, Konqueror, FireFox, tout OpenOffice, GIMP, Inkscape, les outils Mandriva, plein plein de trucs KDE, mais vraiment beaucoup (jusqu'à KolourPaint), etc).

Je conseillerai Mandriva dès qu'ils seront passés à KDE 4.3 (au passage, KDE 4.3.1 est sorti il y a quelques jours, je vous le conseille, Kwin voit plein de ses bugs corrigés).

Vivement la 2010.0 !

> Lire le journal (17 commentaires, moyenne: 2,8).