ubuntu-fr

C'est la saison des benchmarks autour d'eZ Publish Bertrand a fait une intéressante comparaison entre le mode cluster et le mode classique, suivi de près par un article sur ez.no mettant en évidence le gain apporté par le fameux Stale Cache dans la génération du cache de contenu. De mon côté, j'ai adapté les scripts de mon benchmark entre eZ Publish 3.10 et eZ Publish 4 pour comparer cette fois uniquement les performances sur une page en cache de ce site (/blog) avec eZ Publish 4.0.1, eZ Publish 4.1 sans optimisation et eZ Publish 4.1 avec un fichier config.php ; le but étant de déterminer le gain apporté par les différentes améliorations de performances pour un site sur un seul serveur.

Informations techniques

• Serveur : une Dedibox v1 ancienne génération (processeur Via C7 à 2Ghz avec 1Go de RAM)
• Logiciels : Apache 2.2.8, PHP 5.2.4 avec le module xcache, MySQL 5.0.51
• Caractéristique de la page : la page fait les 3 requêtes SQL minimum (session, chargement des langues et détermination de la page concernée)
• Test : plusieurs séries de 500 requêtes avec un concurrence de 2 réalisées avec l'utilitaire ab sur chacune des installations

Le fichier config.php :

define( 'EZP_USE_BUNDLED_COMPONENTS', true );
define( 'EZP_INI_FILEMTIME_CHECK', false );
?>

Résultats

Le résultat est plutôt spectaculaire. La simple mise à jour en 4.1 donne un gain de presque 30% dans la distribution d'une page en cache ! Avec la configuration ci-dessus dans le fichier config.php le gain est même de 50% ! Pendant les phases de tests, j'ai également constaté que la charge de la machine est bien plus faible. Comme d'habitude ces chiffres sont à prendre avec des pincettes, ils représentent le gain sur un site bien optimisé (enfin j'espère) sur un serveur bas de gamme. Un test sur un serveur plus haut de gamme serait vraiment intéressant.

Est ce que les problémes de performance ont bien été corrigé ? voila le sujet d'un commentaire de abhunguru sur un des billets consacrés au Planet eZ Publish.fr ; commentaire qui fait référence à deux billets de Pierre Jean Duvivier à propos de l'expérience eZ Publish chez Edipresse et du passage à Drupal pour résoudre plusieurs problèmes. Il y'a d'autres billets du même auteur sur le sujet dont un ou j'avais laissé un commentaire. Les questions de performances des applications web est un vaste sujet, je vais essayer de pas faire trop long.

Première chose, les informations fournies dans ces billets sont assez confuses voire inexactes (voir le paragraphe intitulé eZpublish ré-invente la compilation en PHP par exemple), je pense qu'il s'agit de la vision non technique de problèmes techniques, en fait ce qui ressort avant tout, c'est la frustration de l'auteur. Ensuite, la comparaison brute des chiffres Drupal / eZ Publish est complètement biaisée. Comparer des installations eZ Publish 3.8 utilisant PHP4 avec des installations de Drupal utilisant probablement PHP5, ce n'est pas très sérieux ! eZ Publish 4.0 (avec PHP5) est 2 fois plus rapide qu'eZ Publish 3.10, alors par rapport à eZ Publish 3.8... Je connais mal Drupal, donc je ne parlerai donc que d'eZ Publish.

Bref, en essayant de démêler tout ça, l'auteur dénonce finalement deux problèmes :

1. Une architecture technique complexe en raison des mauvaises performances supposées du CMS
2. Des difficultés de développement et d'évolution du/des sites.

Architecture, performances...

Avec une estimation à la louche, 500 000 pages vues par jour correspond à moins de 30 pages / secondes en pointe, un nombre certes respectable mais qui ne donne jamais que 8 pages / secondes sur chacun des 4 frontaux qui étaient d'après les articles des bi-Xeon quadcore ! Par expérience, la plupart du temps la cause de ce genre de problèmes est souvent une ou des énormités de configuration au niveau système ou au niveau applicatif. D'ailleurs dans ce cas, je me pose la question de la pertinence d'héberger plusieurs sites sur la même grosse plateforme plutôt que de séparer chaque site sur sa propre plateforme plus légère ?

Mais tout n'est pas 100% blanc ou 100% noir ; la version 3.8 d'eZ Publish était la première à implémenter le mode cluster tel qu'on le connait actuellement (tout ce qui est relatif aux contenus est dans une base de données) et il est clair que ce mode souffrait de défauts de jeunesse importants. Ce mode a été grandement amélioré au fil des versions, en version 3.10 et 4.0, il me semble que ça fonctionne bien et la version 4.1 apporte encore des améliorations importantes avec notamment le Stale cache, Charles-Christian Croix en parle également. Il y a aussi un excellent fil de discussion sur le mode cluster d'eZ Publish et comme suggéré par Bertrand dans ce fil, un article référence sur les architectures de ce type serait le bienvenu ! Donc pour revenir à la question initiale, au niveau des performances, il est clair que la version actuelle d'eZ Publish fonctionne mieux (le contraire serait malheureux).

Le développement

Le second point soulevé par l'auteur est la difficulté de développement et de maintenance (et la maintenance je connais !). Là encore tout n'est pas blanc ou noir. eZ Publish est un outil assez complexe, c'est un fait mais ce n'est pas insurmontable ! Il semble qu'il y ait eu un mélange entre mauvaises pratiques et réels problèmes techniques. Exemple, le fait de mettre des identifiants dans les fichiers de configuration est une pratique à utiliser avec parcimonie. La sur-utilisation de ce genre de mécanisme est clairement une très mauvaise pratique et souvent révélatrice d'une mauvaise conception des contenus. En revanche, le problème de mise à jour d'une classe avec beaucoup d'instances est clairement un vrai problème, ce point a été amélioré mais il existe encore mais il est néanmoins contournable. Et puis les problèmes de performances exposés juste au dessus ne sont probablement pas étranger à d'autres mauvaises pratiques ou d'autres manques dans le développement ou la conception.

Et pour finir quand je lis que d'excellents développeurs PHP ont du mal à utiliser le langage de template d'eZ Publish, on frise le ridicule.

Conclusion ?

Il y a probablement une partie de réels problèmes dans les points remontés dans les articles de Pierre Jean Duvivier (eZ Publish n'est pas parfait) mais il est toujours plus facile de démonter une solution dans son ensemble que de se remettre en cause... Le fait est qu'eZ Publish est utilisé sur une large palette de sites à plus ou moins fort trafic et les chiffres indiqués ne sont pas non plus exceptionnels !

Et pour revenir au commentaire initial, oui les problèmes imputables à eZ Publish sont réglés petit à petit mais il ne faut pas oublier que la qualité de la mise en oeuvre de l'outil est largement aussi importante que l'outil lui-même !

Suite à la parution des tutoriaux "Jobeet", je me permets de rédiger un court article vous permettant d'installer le framework Symfony en 10 minutes sur Ubuntu. Pour les curieux, Symfony est un framework MVC libre écrit en PHP 5. En tant que framework, il facilite et accélère le développement de sites et d'applications Internet et Intranet à conditon bien sûr d'assimiler quelques concepts.

Installation des paquets LAMP

sudo apt-get install apache2 apache2-doc mysql-server php5 libapache2-mod-php5 php5-mysql phpmyadmin php5-xsl php5-cli, php-pear

Quelques détails sur la documentation LAMP d'ubuntu. Afin de bénéficier des commandes internes de Symfony telles que la création d'un schema.xml à partir de fichier yml, php5-xsl semble être indispensable.

Vérifier votre version de php

php -V doit vous retourner une version >= 5.0

Télécharger et installer Symfony 1.2 via Pear

• sudo pear channel-discover pear.symfony-project.com
• sudo pear install symfony/symfony-1.2.1

Vérifier la version de Symfony

symfony -V doit retourner 1.2

Créer l'application

• sudo mkdir /var/www/jobeet
• cd /var/www/
• sudo chmod 777 jobeet/
• symfony generate:project jobeet
• symfony generate:app escaping-strategy=on csrf-secret=UniqueSecret frontend

Configurer votre serveur

sudo gedit /etc/apache2/httpd.conf

Copier-coller ceci :

# Be sure to only have this line once in your configuration
NameVirtualHost 127.0.0.1:8080

# This is the configuration for Jobeet
Listen 127.0.0.1:8080

<VirtualHost 127.0.0.1:8080>
DocumentRoot "/var/www/jobeet/web"
DirectoryIndex index.php
<Directory "/var/www/jobeet/web">
AllowOverride All
Allow from All
</Directory>

Alias /sf /usr/share/php/data/symfony/web/sf
<Directory "/usr/share/php/data/symfony/web/sf">
AllowOverride All
Allow from All
</Directory>
</VirtualHost>

Redémarrer votre serveur via sudo /etc/init.d/apache2 restart

Tester l'application

Dans votre navigateur préféré taper : http://localhost:8080/

Aptana est un environnement de développement intégré orienté web, multi-plateforme et open-source. Il facilite l'écriture du code en fournissant des aides à la saisie pour le JavaScript, l'HTML, les CSS et PHP, Python, Ruby on Rails, Javascript. Cet IDE est disponible en deux versions : standalone ou en plugin pour le célèbre eclipse. Je décrirais ici l'installation sous linux de la première version.

Installation sous Linux Ubuntu d'Aptana Studio

1. Allez sur Aptana Studio et choisissez Standalone pour Installation type et Linux pour operating system
2. Dézipper dans votre /home/user allez dans /home/user/aptana et cliquez sur AptanaStudio

Ajout du langage PHP

L'exemple suivant illustre l'installation du plugin PHP, mais la démarche reste identique pour Ruby on Rails, PyDev.

1. Dans Aptana : Help > Softwares Updates cliquez sur Find And Install ...
2. Choisissez Search for new features to install puis Next
3. Vous avez désormais l'opportunité d'ajouter simplement Aptana Php Environnement, RadRails, Adobe Air, Apple iPhone et iPod touch, Subclipse, (Perforce ?), il suffit de cocher et de cliquez sur next

PS : Il peut être utile d'installer java via sudo apt-get install sun-java6-jre

Avantages d'Aptana

• Assistant pour le code JavaScript, HTML et CSS
• Explorateur de projet + Outline pour regroupement des fonctions
• Envoi FTP/SFTP, téléchargement et synchronisation
• Debuggeur JavaScript avec support de Jquery, Prototype, YUI, Dojo ...
• Système de detection d’erreur et de warning dans votre code
• Multi plateforme (Linux , MacOs, Windows)
• Gratuit,dans sa version normal, 30 jours d'évaluation pour la version Pro puis 495 $

Complétion en fonction du framework JS

1. Dans Window > Show view > References
2. Cocher le framework JS dont vous avez besoin, YUI 2.6 par exemple

Je viens de l'installer depuis quelques heures, ce dernier me semble plus rapide qu'Eclipse et clairement plus adapté pour le html et css. Je ne peux pour l'instant faire des retours d'expérience riches et concrets, notamment sur Jaxer (js côté serveur). J'invite alors les initiés à décrire, donner quelques conseils sur Aptana Standalone

Gandi m’a gentiment fourni une invitation à la bêta de leur service d’hébergement. Je compte y passer ce blog et voir comment se comportent les frameworks Symfony et Django sur ces serveurs virtualisés et scalable.

J’ai donc pris une part (6€ HT/mois) afin d’y installer un serveur web composé d’Apache, de PHP, de MySQL et géré par hosting.py.

Première opération, créer le serveur. J’ai choisi le mode expert et Ubuntu comme distribution (c’est le choix par défaut). Tout ce fait très simplement via le site internet de Gandi. Quelques minutes après la création du serveur via l’interface un mail arrive vous indiquant l’adresse IP de votre serveur tout neuf.

C’est une version personnalisée par Gandi de Gutsy qui est installée, un peu vieille mais très stable, cela me convient parfaitement.

Première opération : mettre à jour la distribution.

Connectez vous via SSH puis passez en root en tapant su (un peu perturbant pour une Ubuntu n’est-ce pas :P) puis tapez la classique commande apt-get update && apt-get dist-upgrade. Cette mise à jour est importante car elle corrige certaines failles de sécurité critiques dont celle désormais célèbre touchant le protocole DNS.

Installer Apache, PHP et MySQL

La commande magique pour installer le tout : apt-get install apache2 mysql-server php5 libapache2-mod-php5 php5-mysql phpmyadmin.

L’utilitaire d’installation vous demandera d’abord de choisir un mot de passe pour le compte root du serveur MySQL puis de sélectionner quel version d’Apache doit être configurée pour être utiliser avec phpMyAdmin : choisissez apache2.

Vous pouvez taper l’adresse IP de votre serveur dans votre navigateur préféré afin de vérifier que tout fonctionne bien. phpMyAdmin est accessible depuis http://<votre_ip>/phpmyadmin/.

Une petite amélioration afin d’augmenter les performances : installons xcache. Comme son nom l’indique, xcache permet de mettre en cache les versions “compilées” des scripts PHP (opcode) et ainsi d’améliorer grandement les performances du langage le plus populaire du web.

Rien de plus facile : apt-get install php5-xcache. La commande /etc/init.d/apache2 restart vous permettra de rendre effective la mise en cache.

Sécurisons tout ça

Très bien, notre serveur fonctionne. Mais ce n’est pas encore la panacée. Une simple requête HTTP GET nous renvoi comme en-têtes :

Date: Tue, 12 Aug 2008 19:51:49 GMT
Server: Apache/2.2.4 (Ubuntu) PHP/5.2.3-1ubuntu6.4
Content-Length: 746
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html;charset=ISO-8859-1

Les en-têtes HTTP sont riches, trop riches : on y apprend que le serveur fonctionne sous la distribution Ubuntu Linux, que le serveur web est Apache en version 2.2.4, que le langage de script PHP en version 5.2.3 est disponible et que les versions installées sont celles pacagées par la distribution (ce qui donne des indices supplémentaires sur la configuration utilisée). Ces informations sont en partie reprises dans les pages d’erreurs et les index générés automatiquement du serveur web.

Même si cacher les noms et numéros de versions des logiciels installés n’améliore pas la sécurité réelle de votre serveur elle le rend moins visible des pirates en herbe et autres robots des amateurs de warez.

Pour masquer les informations distillées par Apache éditons le fichier /etc/apache2/apache2.conf, remplaçons la ligne ServerTokens Full par ServerTokens Prod puis ServerSignature On par ServerSignature Off.

Pour celles que fourni PHP c’est dans /etc/php5/apache2/php.ini que ça se passe. Remplacez expose_php = On par expose_php = Off. Même si cela n’a rien à voir avec les numéros de versions, ça peut être une bonne idée de désactiver églament les magic quotes en remplaçant magic_quotes_gpc = On par magic_quotes_gpc = Off.

Relançons encore une fois Apache /etc/init.d/apache2 restart afin de faire prendre en compte nos modifications, c’est mieux.

Reste MySQL. Nous avons défini un mot de passe pour le compte root lors de l’installation mais il reste quelques brèches importantes comme la possibilité de se connecter sans compte ou celle d’utiliser le compte root depuis l’extérieur (sans passer par une console SSH ou phpMyAdmin - ce qui facilite les attaques par force brute).
Un script fourni nommé mysql_secure_installation permet de remédier à tous ces problèmes. Lancez-le. Excepté pour le changement de mot de passe root que nous venons de définir lors de l’installation je vous conseil de répondre par le choix proposé par défaut à toutes les questions.

Notre serveur est un peu mieux préparé à survivre dans la jungle qu’est le web.

Note : nous n’abordons ici que la sécurisation des composants LAMP de notre serveur. C’est un bon début mais c’est loin d’être une protection absolue ou suffisante.

Installer hosting.py

hosting.py est un petit logiciel que j’ai développé qui permet de gérer de manière très simple des comptes web. Il se base sur le système de gestion des utilisateurs UNIX et automatise les tâches les plus courantes lors de l’administration d’un petit serveur web mutualisé à savoir la mise en place et la modification de compte comprenant un utilisateur UNIX (accès SSH, FTP, …), un hôte virtuel apache, un compte et une base de données MySQL.

Il est conçu pour fonctionner avec les distributions basées sur Debian, Ubuntu en particulier. Il permet de simplement séparer les comptes des différents sites qu’hébergera votre serveur, ce qui n’est pas un mal question sécurité.

Commençons par installer les dépendances nécessaires à la récupération et à l’utilisation de mon script : apt-get install subversion python-mysqldb

Créons maintenant le squelette du répertoire de base des comptes web :

• mkdir /etc/skel-www
• mkdir /etc/skel-www/logs
• mkdir /etc/skel-www/public_html

Comme son nom l’indique, logs accueillera les logs de connexion d’Apache (on pourra plus tard configurer AWstats pour générer des statistiques) et public_html sera le répertoire web de nos utilisateurs.

Récupérons la dernière version de hosting.py via Subversion : svn checkout http://debian-hosting.googlecode.com/svn/trunk/ debian-hosting-read-only

Éditez la variable MYSQL_PASSWD du fichier debian-hosting/hosting.py pour qu’elle contienne le mot de passe MySQL de l’utilisateur root puis donnez les droits en exécution sur ce même fichier en tapant chmod a+x debian-hosting/hosting.py.

Pour créer un compte utilisateur, passez en root avec la commande su puis tapez debian-hosting/hosting.py add monsite.com. Vous pouvez voir les informations de connexion s’afficher, notez les

Un sous domaine du type monsite.com.lapin-blanc.net est automatiquement créé (pour être effectif, il nécessite que lapin-blanc.net, notre domaine de test, dispose d’un wildcard dans ses entrées DNS).

Je vous conseil de le laisser à des fins de test et de debug, néanmoins un vrai nom de domaine c’est mieux. Toujours en tant que root éditez le fichier généré automatiquement nommé /etc/apache2/sites-available/monsite.com et transformez la ligne ServerName monsite.com.lapin-blanc.net en ServerAlias monsite.com.lapin-blanc.net. Ajoutez au dessus de celle-ci ServerName monsite.com.

Rechargez Apache (toujours en root) : /etc/init.d/apache2 reload

Votre serveur web est le site que vous avez créé sont fonctionnels si vos entrées DNS sont bien configurées. Placez vos fichiers web dans /home/monsite.com/public_html/ pour qu’ils soient visibles sur http://monsite.com

Bonjour!

Vous n’êtes pas sans savoir que opensuse 11 est sortie.

Je vous propose un petit tutoriel concernant son installation sans gravure, en passant par grub.

Le secret: faire en sorte que, au démarrage, grub lance le média d’installation (dvd ou cd d’installation) de opensuse.

Prérequis

Il vous faut une partition d’au moins 4,3 Gio, sur laquelle va venir se placer l’image décompressée du dvd d’installation d’opensuse. Le point de montage de cette partition ne pourra pas être défini lors de la procédure d’installation, puisqu’il s’agit de la partition contenant le média d’installation.

Grub doit être installé (ceci peut-etre fait via un live cd quelconque si vous avez windows, ou le Grub “habituel” si vous avez déjà une distribution installée.

Quelques connaissances en matière de dénominations de disques durs…mais rien de bien grave, puisque j’y suis arrivé

Fonctionnement

Grub se lance lors du démarrage de l’ordinateur, et permet de choisir quel système lancer. Le truc est de rajouter une ligne proposant l’installation de opensuse: grub va booter sur le kernel du media d’installation et proposer une installation “classique”.

Préparation

Il vous faut télécharger une iso du dvd d’installation (ca doit aussi marcher avec un cd…retours d’utilisation bienvenus :)): http://software.opensuse.org/.

Ensuite, il faut la monter et copier son contenu sur la partition qui va servir d’installation:

En console:

On crée le dossier dans lequel l’iso sera montée:
$ mkdir /home/votre identifiant/opensuse11
En root, on monte:
# mount -o loop -t iso9660 /chemin/vers/l'iso/d'opensuse11.iso /home/votre identifiant/opensuse11
Ensuite, on copie le contenu de l’iso:
# cp -a /home/votre/identifiant/opensuse11/* /la/partition/que/vous/choisissez/opensuse (retenez la !!!)

Modification de Grub

Laissez faire le système. une fois cette copie terminée, il faut modifier Grub, en modifiant le fichier /boot/grub/menu.lst en ce sens:
title Installation opensuse v11
root (hd0,5)
kernel /le chemin sur la partition/que/vous/choisissez/opensuse/boot/i386/loader/linux splash=silent showopts
initrd /le chemin sur la partition/que/vous/choisissez/opensuse/boot/i386/loader/initrd

Notez que la dénomination (hd0,5) correspond à la 6e partition de mon premier disque dur.

Si votre chemin vers l’image décompressée de opensuse sur la 1 partition du 2e disque dur, par exemple, alors, ca sera dénommé comme ceci: (hd1,0) ==>Le premier chiffre correspond au disque dur, le deuxième, à la partition. grub commence à compter à 0 (zéro), et pas à 1 !

Pour connaître ses partition, en console:
mount
Par exemple, chez moi, ça donne ceci:
/dev/hda1 on / type ext3 (rw)
none on /proc type proc (rw)
/dev/hda6 on /home type ext3 (rw)
/dev/hda7 on /media/autre_distrib type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
none on /sys/fs/fuse/connections type fusectl (rw)

Voila, vous avez mis à jour vitre fichier menu.lst.

Installation

Il suffit maintenant de redémarrer l’ordinateur, et, quand Grub se lance, choisir l’entrée “installation opensuse v11″.

Normalement, le kernel devrait se lancer, et ensuite, une interface austère vous proposant de “Make sure the CD1 is in the drive”. Répondez “Back”

Choisissez votre langue, pays et clavier

Choisissez ensuite “démarrer l’installation ou le système”

Ensuite “démarrer l’installation ou la mise à jour”

Sélectionner le support source -> disque dur -> /votre partition où se trouve l’image décompressée de opensuse  -> /le chemin/sur/cette partition/vers le dossier “opensuse”.

L’installation “normale” démarre, graphiquement, comme d’hab’.

Cas pratique

Voici les commandes que j’ai effectuées sur mon système:
$ mkdir /home/splitsch/Bureau/opensuse11
# mount -o loop -t iso9660 /home/téléchargement/opensuse11.iso /home/splitsch/Bureau/opensuse11
$ cp -a /home/splitsch/Bureau/opensuse11/* /home/splitsch/bureau/opensuse

Mon menu.lst:
title Installation Suse v11
root (hd0,5)
kernel /home/splitsch/Bureau/opensuse/boot/i386/loader/linux splash=silent showopts
initrd /home/splitsch/Bureau/opensuse/boot/i386/loader/initrd

Lors de l’installation, j’ai choisi le disque dur sda6, et comme chemin, j’ai choisi : /splitsch/Bureau/opensuse/

Conclusion

Et voilà le travail !

Voici une méthode qui est plus difficile, certes, mais plus rapide et qui coute moins de dvd

Merci à alionet et Tyrtamos, j’ai adapté la méthode grâce à eux

Cette méthode fonctionne peut-être avec d’autre distributions! Je serai heureux d’avoir des retours d’expérience à ce niveau-là

Get the facts est un programme de Microsoft qui vise à démontrer la supériorité de son produit Windows dans certains domaines. En fait il sert surtout à discréditer les qualités de systèmes concurrents, et tout particulièrement de GNU/Linux.

Comme on peut l’imaginer, les “faits” exposés sont souvent biaisés et la firme de Redmond y voit surtout ce quelle veut bien y voir.

Pour preuve le dernier Get the facts veut comparer l’installation de Perl et de Php sous Windows server et Ubuntu 7.04. Comme le relate bien mieux que moi le blog GNU Squad, il semblerait que la bonne foi ne soit pas encore de mise.

Petits extraits de choix:

[...] le screencast Windows : celui-ci démarre par l’installation de Perl en mode CGI accompagné d’un script de test, pour cela, ils ont eu besoin d’un double clic, de 32 clics et de 4 commandes à taper puis [...] à l’installation de PHP, [...] et qui a nécessité quant à lui, 5 double-clics et 18 clics ce qui fait au total : 6 double-clics, 50 clics et 4 commandes à taper !!!

[...] screencast Ubuntu: [...] donne au total 2 double-clics et 7 commandes à taper.

Malgré un temps d’installation plus court sur le système Ubuntu et de nombreuses irrégularités constatées: installation en cgi comparée à une installation de modules, temps de téléchargement des programmes non décomptés pour Windows, utilisation sûrement volontaire de la ligne de commande plutôt que de synaptic (ou autre); il semblerait que ces screencast devraient démontrer une supériorité de l’os privateur.

Bref si l’on résume on obtient un FUD, un protocole de test abusif, une bonne grosse dose de mauvaise foie et de méthode Coué.

N’empêche que l’on revient sur un point que j’ai soulevé récemment (un an c’est récemment ici :q), les gestionnaire de paquets actuellement sont assez insatisfaisant s’agissant d’une utilisation grand public.

Malgré leur caractère crucial des système GNU/Linux n’apparaissent pas comme une évidence, ou même comme un des premiers avantages que fournissent ses systèmes. Il est agréable de voir que des initiatives pour améliorer ce point sont en chantier, comme l’ajout de captures d’écrans dans le menu ajouter/supprimer d’Ubuntu.