--Apple-Mail=_3BAF6BCA-BA17-43D9-9EC0-F4B61FBB56F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Bonjour et merci de cet excellente analyse.
En tant qu’administrateur de nombreux serveurs sur un réseau dont j’administre et assure l’intégrité global des accès aussi bien vis-à -vis du fournisseur d’accès que des utilisateurs et devant absolument assurer au maximum la sécurité
globale du réseau que j'administre mais ne disposant pas des ressources des gros opérateurs (OVH, IONOS, ScaleWay, Google, AMV, Azure, …) je dois bien avouer que je ne peux que dire que le taux de contraintes sur la tenue des serveurs est bien une
cote mal taillée. Il faut aussi tenir compte du fait que l’utilisateur final, même s’il connait *nix, n’a souvent que peu de connaissances des conséquences d’une serveur mal sécurisé et a trop souvent l’idée du « ça ne me concerne pas »
sans se soucier du fait que ça pourrait bien le concerner directement si son serveur est victime de l’attaque sur le serveur du voisin…
Il y a aussi un point négatif sur les déploiements intégrés :
* Le fait qu’on ne peut suivre raisonnablement les N sources d’émission (FlatPack, Snap, AppImage, Docker, …) en fonction des outils utilisés sur chaque serveur. Cela alourdi conséquemment le suivit des serveurs sans en garantir l’intégrité.
Quant à l’argument de bibliothèques « ante-dilluviennes » présentes sur les distributions LTS, vous me permettrez de douter de celui-ci. Soit le développement est … en développement, et oui, le fait d’avoir la dernière version d’une
bibliothèque peut être importante mais on ne peut présenter ce développement comme opérationnel et distribuable à tous. Soit on souhaite le distribuer en tant qu’opérationnel (professionnel) et là , il est plus sérieux de s’appuyer sur des
versions de bibliothèques solides, opérationnelles et stables fournies par la communauté plutôt que le dernier petit bijou dont on ne connait pas véritablement et la stabilité et même finalement l’avenir.
Pour un responsable de sécurité, lire comme un argument positif que les containers peuvent être la solution car phagocytées; lire que « S'il est strict et propre, l'application n'a qu'un accès limité au système » hérisse le poil. D’autre part
si le développeur gagne du temps et de la sueur en limitant ses distributions il se charge d’une lourde charge de suivit et de mise-à -jour dans l’avenir immédiat.
Je suis d’accord sur les conclusions même si je les redoute.
Toutes ces réflexions viennent finalement de la faiblesse des ressources humaines disponibles à tous les étages de la construction, du suivit des applications proposées.
Le développement « en continu » pourrait être LA solution à la seule condition de savoir positionner le curseur entre ce qu’est un développement d’un passage en version stable. C’est toute la science et le sérieux d’une distribution comme
Debian en fait. Mais cela demande … de lourdes ressources humaines, une procédure stricte à la fois de validation et de tests. C’est tout un travail dans l’ombre et peu valorisé ni valorisante. Or, malheureusement, ce n’est pas toujours le cas
des modules en développement et pas parce que ces développeurs ne sont pas sérieux.
En tout cas merci à vous pour ce point de vue explicite et circonstancié.
Le 9 juin 2025 à 23:36, Sébastien Dinot <sebastien.dinot@free.fr> a écrit :
Bonjour,
Alex PADOLY a écrit :
Quelle est l'utilité de SNAP?
Je trouve que Debian gère très bien les paquets.
Grosso modo, le déploiement d'une application peut s'envisager de deux manières bien différentes :
* Déploiement intégré (au système hôte) : l'application a été conçue et
compilée pour fonctionner avec les bibliothèques disponibles
nativement sur le système hôte. Dans ce cas, le « paquet » de
l'application ne fournit que l'application et les ressources externes
associées (documentation, fichiers de configuration, icônes et autres
ressources multimédia spécifiques).
* Déploiement autoportant : l'objectif est de rendre le plus possible
l'application indépendante du système hôte, de s'approcher d'un
fonctionnement en vase clos. En plus des ressources précédemment
évoquées, le paquet fournit alors l'ensemble des bibliothèques dont
dépend l'application, dans la version prévue par le développeur de
l'application.
En schématisant un peu, la première approche est l'approche historique
des systèmes Unix, la seconde, est celle de macOS et, dans une moindre mesure, de MS-Windows. C'est aussi celle des conteneurs plus ou moins cloisonnés que sont FlatPak, AppImage, Snap et Docker.
Chacune des approches a des avantages et inconvénients, différents (ou
plus ou moins prégnants) selon qu'on est développeur de l'application, administrateur du système ou utilisateur de l'application.
Pour l'administrateur :
* Le déploiement intégré facilite la maintenance du système et réduit
les ressources requises sur disque et en RAM. En mettant à jour la
bibliothèque lorsqu'un bogue ou une faille de sécurité est identifié,
on patche d'un coup toutes les applications qui l'utilisent. C'est
idéal du point de vue de la sécurité. Une seule copie de la
bibliothèque est stockée sur le disque et une seule copie est chargée
en mémoire. Le déploiement intégré est donc moins couteux en
ressources matérielles, mais les ressources disponibles augmentant
avec le temps, cet argument porte de moins en moins (sauf, sans doute,
dans l'embarqué). Par contre, si l'ABI de la bibliothèque change,
toutes les applications qui l'utilisent doivent être recompilées et un
nouveau paquet doit être publié pour chacune d'entre elles. La
propagation des corrections peut de ce fait être ralentie.
* Le déploiement autoportant fait que la mise à jour du système est sans
effet sur l'application. Celle-ci, ou plutôt son paquet, doit faire
l'objet d'une mise à jour spécifique. La mise à disposition d'une
nouvelle version d'un paquet dépend de la réactivité des mainteneurs
de l'application. La sécurisation du système est donc progressive.
Pour l'administrateur et du point de vue de la sécurité, c'est un
cauchemar. Ce problème est cependant contrebalancé par le
cloisonnement qu'opèrent les conteneurs. S'il est strict et propre,
l'application n'a qu'un accès limité au système. Les failles de
sécurité dont elle souffre ont donc un pouvoir de nuisance limité.
Quelle stratégie l'emporte auprès des administrateurs ? Pour l'instant, aucune, même si on sent bien que le vent change et que le déploiement autoportant est en train de gagner des adeptes (pas grâce à Snap,
FlatPak ou AppImage, mais grâce aux véritables conteneurs que sont
Docker et consors).
Pour le développeur :
* Le déploiement intégré est un fardeau qui lui prend une énergie
considérable et l'empêche de se concentrer sur des fonctions utiles et
des tâches plus motivantes. En effet, le développeur n'est pas libre
d'utiliser la version qui lui plait d'une bibliothèque, mais celle
disponible sur l'environnement cible. Lorsque les environnements
cibles se multiplient, les versions aussi. Et ce n'est pas qu'un
problème de plateforme GNU/Linux ou MS-Windows ou macOS. La version de
la bibliothèque mise à disposition diffère selon la distribution
(Debian, Mint, Alma, Manjaro, OpenSuse…), selon la version de cette
distribution (Debian Bullseye, Bookworm ou Trixie), selon que le
système est mis à jour six fois par jour ou une fois par semestre,
selon qu'il est déployé sur une plateforme Intel ou ARM. L'API, les
fonctions offertes, les performances, les bogues ne sont donc pas les
mêmes d'un environnement à l'autre. Et je ne parle même pas des
options de compilation choisies par les mainteneurs. En outre, une
application dépend en général de plusieurs bibliothèques, au point
qu'il devient « impossible » de trouver un socle commun à tous les
environnements.
Le développeur doit s'interdire d'utiliser les versions trop récentes
des bibliothèques, dont les fonctions qui lui font de l'œil et
pourraient résoudre efficacement ses problèmes. C'est frustrant.
Lorsqu'un utilisateur lui signale un bogue, le développeur doit
précisément caractériser son environnement, puis réussir à reproduire
cet environnement s'il ne reproduit pas le bogue dans son
environnement de travail habituel. C'est usant. J'ai eu de nombreux
témoignages directs à ce sujet et je connais plus d'un projet qui
a cessé de supporter certains environnements pour réduire la charge
sur les mainteneurs.
* Il ne faut donc pas s'étonner que de plus en plus de projets décident
de s'émanciper, qu'ils créent dans un conteneur un environnement
parfaitement maitrisé par eux et autoportant, et qu'ils déclarent ne
supporter que les déploiements effectués via ce conteneur (c'est par
exemple le cas de Discourse). Le déploiement autoportant engendre
cependant de nouvelles responsabilités pour les développeurs de
l'application. Puisqu'ils ont créé l'environnement, ils en deviennent
responsables. Il leur incombe d'assurer la veille technologique et
sécuritaire sur les composants qu'ils utilisent, et de fournir dans
les meilleurs délais des versions corrigeant les problèmes.
Un déploiement qui s'abstrait des contraintes du système, c'est aussi
ce que recherchent les développeurs Python avec leurs « virtual
envs », mais c'est aussi ce qu'apprécient les développeurs Rust et Go.
Et là , on ne parle même pas de Snap ou de Docker.
Je pense que de plus en plus de développeurs parmi ceux qui veulent que
leur application fonctionne « partout » vont succomber au charme des déploiements autoportants.
Pour l'utilisateur :
* Il est bien souvent administrateur de son propre poste ; ce que j'ai
dit pour l'administrateur vaut en partie pour l'utilisateur.
* Mais de manière générale, un simple utilisateur est cependant moins
sensible aux questions de sécurité. Son besoin n'est pas d'assurer
l'intégrité d'un système, mais la production d'un document, la
réalisation d'une tâche, au moyen d'un ou plusieurs logiciels. Cet
utilisateur peut être frustré de ne disposer que d'une version
antédiluvienne de son outil préféré dans les dépôts natifs de sa
distribution. S'il apprend qu'une version bien plus récente de l'outil
est disponible dans un dépôt tiers ou via un paquet Snap ou AppImage,
il hésitera rarement à s'approvisionner par ce biais.
L'utilisateur n'a guère conscience des enjeux et il est seulement intéressé par la satisfaction de ses besoins, ce qui se comprend (j'ai moi-même ce comportement dans beaucoup d'autres domaines, par exemple,
avec ma voiture : la seule chose qui m'intéresse est qu'elle fonctionne
et m'emmène à bon port, je prends rendez-vous au garage pour l'entretien
et je paie, le reste, c'est le problème du garagiste, pas le mien).
Au final, quoi qu'on en pense, je suis persuadé que l'approche
déploiement autoportant / conteneur va finir par l'emporter et qu'un
jour où l'autre, notre système d'exploitation se résumera à un socle minimaliste faisant tourner peu ou prou tous nos outils dans autant de conteneurs à la porosité minimale. Il me semble que c'est la voie que proposent déjà les distributions Ubuntu Core et Zorin OS.
Sébastien
--
Sébastien Dinot, sebastien.dinot@free.fr
https://www.palabritudes.net/
Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer !
--
M Pierre Malard
« L'émancipation politique doit marcher de pair avec l'émancipation
sociale ou les résultats sont désastreux »
Romain Gary - "Les racines du ciel"
|\ _,,,---,,_
/,`.-'`' -. ;-;;,_
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_) πr
perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24Ï€r::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
--Apple-Mail=_3BAF6BCA-BA17-43D9-9EC0-F4B61FBB56F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Bonjour et merci de cet excellente analyse.<div class=""><br
class=""></div><div class="">En tant qu’administrateur de nombreux serveurs sur un réseau dont j’administre et assure l’intégrité global des accès aussi bien vis-à -vis du fournisseur d’accès que des utilisateurs et devant absolument assurer
au maximum la sécurité globale du réseau que j'administre mais ne disposant pas des ressources des gros opérateurs (OVH, IONOS, ScaleWay, Google, AMV, Azure, …) je dois bien avouer que je ne peux que dire que le taux de contraintes sur la tenue des
serveurs est bien une cote mal taillée. Il faut aussi tenir compte du fait que l’utilisateur final, même s’il connait *nix, n’a souvent que peu de connaissances des conséquences d’une serveur mal sécurisé et a trop souvent l’idée du «&
nbsp;ça ne me concerne pas » sans se soucier du fait que ça pourrait bien le concerner directement si son serveur est victime de l’attaque sur le serveur du voisin…</div><div class=""><br class=""></div><div class="">Il y a aussi un point né
gatif sur les déploiements intégrés :</div><div class="">* Le fait qu’on ne peut suivre raisonnablement les N sources d’émission (FlatPack, Snap, AppImage, Docker, …) en fonction des outils utilisés sur chaque serveur. Cela alourdi consé
quemment le suivit des serveurs sans en garantir l’intégrité.</div><div class=""><br class=""></div><div class="">Quant à l’argument de bibliothèques « ante-dilluviennes » présentes sur les distributions LTS, vous me permettrez de
douter de celui-ci. Soit le développement est … en développement, et oui, le fait d’avoir la dernière version d’une bibliothèque peut être importante mais on ne peut présenter ce développement comme opérationnel et distribuable à tous.
Soit on souhaite le distribuer en tant qu’opérationnel (professionnel) et là , il est plus sérieux de s’appuyer sur des versions de bibliothèques solides, opérationnelles et stables fournies par la communauté plutôt que le dernier petit bijou
dont on ne connait pas véritablement et la stabilité et même finalement l’avenir.</div><div class=""><br class=""></div><div class="">Pour un responsable de sécurité, lire comme un argument positif que les containers peuvent être la solution car
phagocytées; lire que « S'il est strict et propre, l'application n'a qu'un accès limité au système » hérisse le poil. D’autre part si le développeur gagne du temps et de la sueur en limitant ses distributions il se charge d’une lourde
charge de suivit et de mise-à -jour dans l’avenir immédiat.</div><div class=""><br class=""></div><div class="">Je suis d’accord sur les conclusions même si je les redoute.</div><div class=""><br class=""></div><div class="">Toutes ces réflexions
viennent finalement de la faiblesse des ressources humaines disponibles à tous les étages de la construction, du suivit des applications proposées. </div><div class="">Le développement « en continu » pourrait être LA solution à la
seule condition de savoir positionner le curseur entre ce qu’est un développement d’un passage en version stable. C’est toute la science et le sérieux d’une distribution comme Debian en fait. Mais cela demande … de lourdes ressources humaines,
une procédure stricte à la fois de validation et de tests. C’est tout un travail dans l’ombre et peu valorisé ni valorisante. Or, malheureusement, ce n’est pas toujours le cas des modules en développement et pas parce que ces développeurs ne
sont pas sérieux.</div><div class=""><br class=""></div><div class="">En tout cas merci à vous pour ce point de vue explicite et circonstancié.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Le 9 juin 2025 à 23:36, Sé
bastien Dinot <<a href="mailto:
sebastien.dinot@free.fr" class="">
sebastien.dinot@free.fr</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">Bonjour,<br class=""><br class="">Alex PADOLY a écrit :<br class=""><
blockquote type="cite" class="">Quelle est l'utilité de SNAP?<br class="">Je trouve que Debian gère très bien les paquets.<br class=""></blockquote><br class="">Grosso modo, le déploiement d'une application peut s'envisager de deux<br class="">maniè
res bien différentes :<br class=""><br class="">* Déploiement intégré (au système hôte) : l'application a été conçue et<br class=""> compilée pour fonctionner avec les bibliothèques disponibles<br class=""> nativement sur le
système hôte. Dans ce cas, le « paquet » de<br class=""> l'application ne fournit que l'application et les ressources externes<br class=""> associées (documentation, fichiers de configuration, icônes et autres<br class="">
ressources multimédia spécifiques).<br class=""><br class="">* Déploiement autoportant : l'objectif est de rendre le plus possible<br class=""> l'application indépendante du système hôte, de s'approcher d'un<br class="">
fonctionnement en vase clos. En plus des ressources précédemment<br class=""> évoquées, le paquet fournit alors l'ensemble des bibliothèques dont<br class=""> dépend l'application, dans la version prévue par le développeur de<br class=
""> l'application.<br class=""><br class="">En schématisant un peu, la première approche est l'approche historique<br class="">des systèmes Unix, la seconde, est celle de macOS et, dans une moindre<br class="">mesure, de MS-Windows. C'est aussi
celle des conteneurs plus ou moins<br class="">cloisonnés que sont FlatPak, AppImage, Snap et Docker.<br class=""><br class="">Chacune des approches a des avantages et inconvénients, différents (ou<br class="">plus ou moins prégnants) selon qu'on est
développeur de l'application,<br class="">administrateur du système ou utilisateur de l'application.<br class=""><br class="">Pour l'administrateur :<br class=""><br class="">* Le déploiement intégré facilite la maintenance du système et réduit<
br class=""> les ressources requises sur disque et en RAM. En mettant à jour la<br class=""> bibliothèque lorsqu'un bogue ou une faille de sécurité est identifié,<br class=""> on patche d'un coup toutes les applications qui l'
utilisent. C'est<br class=""> idéal du point de vue de la sécurité. Une seule copie de la<br class=""> bibliothèque est stockée sur le disque et une seule copie est chargée<br class=""> en mémoire. Le déploiement intégré est
donc moins couteux en<br class=""> ressources matérielles, mais les ressources disponibles augmentant<br class=""> avec le temps, cet argument porte de moins en moins (sauf, sans doute,<br class=""> dans l'embarqué). Par contre, si l'
ABI de la bibliothèque change,<br class=""> toutes les applications qui l'utilisent doivent être recompilées et un<br class=""> nouveau paquet doit être publié pour chacune d'entre elles. La<br class=""> propagation des corrections
peut de ce fait être ralentie.<br class=""><br class="">* Le déploiement autoportant fait que la mise à jour du système est sans<br class=""> effet sur l'application. Celle-ci, ou plutôt son paquet, doit faire<br class=""> l'objet d'une
mise à jour spécifique. La mise à disposition d'une<br class=""> nouvelle version d'un paquet dépend de la réactivité des mainteneurs<br class=""> de l'application. La sécurisation du système est donc progressive.<br class="">
Pour l'administrateur et du point de vue de la sécurité, c'est un<br class=""> cauchemar. Ce problème est cependant contrebalancé par le<br class=""> cloisonnement qu'opèrent les conteneurs. S'il est strict et propre,<br class="">
l'application n'a qu'un accès limité au système. Les failles de<br class=""> sécurité dont elle souffre ont donc un pouvoir de nuisance limité.<br class=""><br class="">Quelle stratégie l'emporte auprès des administrateurs ? Pour l'
instant,<br class="">aucune, même si on sent bien que le vent change et que le déploiement<br class="">autoportant est en train de gagner des adeptes (pas grâce à Snap,<br class="">FlatPak ou AppImage, mais grâce aux véritables conteneurs que sont<
br class="">Docker et consors).<br class=""><br class="">Pour le développeur :<br class=""><br class="">* Le déploiement intégré est un fardeau qui lui prend une énergie<br class=""> considérable et l'empêche de se concentrer sur des
fonctions utiles et<br class=""> des tâches plus motivantes. En effet, le développeur n'est pas libre<br class=""> d'utiliser la version qui lui plait d'une bibliothèque, mais celle<br class=""> disponible sur l'environnement cible.
Lorsque les environnements<br class=""> cibles se multiplient, les versions aussi. Et ce n'est pas qu'un<br class=""> problème de plateforme GNU/Linux ou MS-Windows ou macOS. La version de<br class=""> la bibliothèque mise Ã
disposition diffère selon la distribution<br class=""> (Debian, Mint, Alma, Manjaro, OpenSuse…), selon la version de cette<br class=""> distribution (Debian Bullseye, Bookworm ou Trixie), selon que le<br class=""> système est mis Ã
jour six fois par jour ou une fois par semestre,<br class=""> selon qu'il est déployé sur une plateforme Intel ou ARM. L'API, les<br class=""> fonctions offertes, les performances, les bogues ne sont donc pas les<br class=""> mêmes d'
un environnement à l'autre. Et je ne parle même pas des<br class=""> options de compilation choisies par les mainteneurs. En outre, une<br class=""> application dépend en général de plusieurs bibliothèques, au point<br class="">
qu'il devient « impossible » de trouver un socle commun à tous les<br class=""> environnements.<br class=""><br class=""> Le développeur doit s'interdire d'utiliser les versions trop récentes<br class=""> des bibliothèques,
dont les fonctions qui lui font de l'Å“il et<br class=""> pourraient résoudre efficacement ses problèmes. C'est frustrant.<br class=""> Lorsqu'un utilisateur lui signale un bogue, le développeur doit<br class=""> précisément caractÃ
©riser son environnement, puis réussir à reproduire<br class=""> cet environnement s'il ne reproduit pas le bogue dans son<br class=""> environnement de travail habituel. C'est usant. J'ai eu de nombreux<br class=""> témoignages
directs à ce sujet et je connais plus d'un projet qui<br class=""> a cessé de supporter certains environnements pour réduire la charge<br class=""> sur les mainteneurs.<br class=""><br class="">* Il ne faut donc pas s'étonner que de plus
en plus de projets décident<br class=""> de s'émanciper, qu'ils créent dans un conteneur un environnement<br class=""> parfaitement maitrisé par eux et autoportant, et qu'ils déclarent ne<br class=""> supporter que les dé
ploiements effectués via ce conteneur (c'est par<br class=""> exemple le cas de Discourse). Le déploiement autoportant engendre<br class=""> cependant de nouvelles responsabilités pour les développeurs de<br class=""> l'application.
Puisqu'ils ont créé l'environnement, ils en deviennent<br class=""> responsables. Il leur incombe d'assurer la veille technologique et<br class=""> sécuritaire sur les composants qu'ils utilisent, et de fournir dans<br class=""> les
meilleurs délais des versions corrigeant les problèmes.<br class=""><br class=""> Un déploiement qui s'abstrait des contraintes du système, c'est aussi<br class=""> ce que recherchent les développeurs Python avec leurs « virtual<br
class=""> envs », mais c'est aussi ce qu'apprécient les développeurs Rust et Go.<br class=""> Et là , on ne parle même pas de Snap ou de Docker.<br class=""><br class="">Je pense que de plus en plus de développeurs parmi ceux qui
veulent que<br class="">leur application fonctionne « partout » vont succomber au charme des<br class="">déploiements autoportants.<br class=""><br class="">Pour l'utilisateur :<br class=""><br class="">* Il est bien souvent administrateur de
son propre poste ; ce que j'ai<br class=""> dit pour l'administrateur vaut en partie pour l'utilisateur.<br class=""><br class="">* Mais de manière générale, un simple utilisateur est cependant moins<br class=""> sensible aux questions
de sécurité. Son besoin n'est pas d'assurer<br class=""> l'intégrité d'un système, mais la production d'un document, la<br class=""> réalisation d'une tâche, au moyen d'un ou plusieurs logiciels. Cet<br class=""> utilisateur peut
être frustré de ne disposer que d'une version<br class=""> antédiluvienne de son outil préféré dans les dépôts natifs de sa<br class=""> distribution. S'il apprend qu'une version bien plus récente de l'outil<br class=""> est
disponible dans un dépôt tiers ou via un paquet Snap ou AppImage,<br class=""> il hésitera rarement à s'approvisionner par ce biais.<br class=""><br class="">L'utilisateur n'a guère conscience des enjeux et il est seulement<br class="">inté
ressé par la satisfaction de ses besoins, ce qui se comprend (j'ai<br class="">moi-même ce comportement dans beaucoup d'autres domaines, par exemple,<br class="">avec ma voiture : la seule chose qui m'intéresse est qu'elle fonctionne<br class="">et
m'emmène à bon port, je prends rendez-vous au garage pour l'entretien<br class="">et je paie, le reste, c'est le problème du garagiste, pas le mien).<br class=""><br class="">Au final, quoi qu'on en pense, je suis persuadé que l'approche<br class="">
déploiement autoportant / conteneur va finir par l'emporter et qu'un<br class="">jour où l'autre, notre système d'exploitation se résumera à un socle<br class="">minimaliste faisant tourner peu ou prou tous nos outils dans autant de<br class="">
conteneurs à la porosité minimale. Il me semble que c'est la voie que<br class="">proposent déjà les distributions Ubuntu Core et Zorin OS.<br class=""><br class="">Sébastien<br class=""><br class=""><br class="">-- <br class="">Sébastien Dinot, <a
href="mailto:
sebastien.dinot@free.fr" class="">
sebastien.dinot@free.fr</a><br class=""><a href="
https://www.palabritudes.net/" class="">
https://www.palabritudes.net/</a><br class="">Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer !<
br class=""><br class=""></div></div></blockquote></div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-
white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode:
space; line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-
word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div style="margin: 0px; font-size: 10px; font-family: "Courier New";" class="">-- </div><div style="margin: 0px; font-size: 10px; font-
family: "Lucida Grande";" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>M Pierre Malard</div><div style="margin: 0px; font-size: 10px; font-family: "Courier New"; min-height: 11px;" class=""><br class=""></
</div></div><div style="margin: 0px; font-size: 10px; font-family: "Courier New"; min-height: 11px;" class=""><div style="font-size: 12px; margin: 0px; font-family: Times;" class=""> « <i class="">L'émancipation politique
doit marcher de pair avec l'émancipation</i></div><div style="font-size: 12px; margin: 0px; font-family: Times;" class=""><i class=""> sociale ou les résultats sont désastreux </i>»</div><div style="font-size: 12px; margin: 0px;
font-family: Times;" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span> Romain Gary - "Les racines du ciel"</div><div style="margin: 0px;" class=""> |\ _,,,---,,_</div><div
style="margin: 0px;" class=""> /,`.-'`' -. ;-;;,_</div><div style="margin: 0px;" class=""> |,4- ) )-,_. ,\ ( `'-'</div><div style="margin: 0px;" class=""> '---''(_/--'&
nbsp; `-'\_) πr</div><div style="font-size: 12px; margin: 0px; font-family: Times; min-height: 14px;" class=""><br class=""></div><div style="margin: 0px;" class="">perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A-
) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24Ï€r::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'</div><div class=""><br class=""></div></div></div></div></div><br class="Apple-interchange-newline"><br class="Apple-interchange-
newline">
</div>
<br class=""></div></body></html> --Apple-Mail=_3BAF6BCA-BA17-43D9-9EC0-F4B61FBB56F3--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.2
Comment: GPGTools -
http://gpgtools.org
iQEzBAEBCgAdFiEEcPBlpkb251eMzn+mKsHruJuVZaAFAmhH6EgACgkQKsHruJuV ZaCbuQgAmRHTdYgEE0dMxDToq23EhJeHSXR5UomdZv5e/tApfiJYhSC7emkB53WN oXTJDH6VbussFG8BeDGn1QiD+/Oz3wD2gFIqF9WXIMNQ3wvh2Ta00BvUfNVuBo2K fMbrdm7uKBLIZO+hWZ0UHnXDQ7Psi3xcmYHYPN7gx/5TIx73B+vcozh4hYhbpFyV RTOdEHwzrJY6H8AO1Ldl86g3+JqV/FxcAmpwPevlKyh0eNqnX+ilAA09HaotPDPk prb1+G0cl/uXgKhRlMQ12WKoEOQLPTtLwditSaddH8t8AdmIsp9u8oI66vSlhEdM xHYsEMhIssyzAcdcb8MefrOSwv2ZIg==
=oI+3
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)