Re: Appimage Vs Snap Vs Compilation des sources
Bonjour,
Pierre Malard a écrit :
> 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é.
Je comprends donc qu'il s'agit d'un point négatif pour les déploiements
autoportants, et non intégrés.
> Quant à l’argument de bibliothèques « ante-dilluviennes » présentes
> sur les distributions LTS, vous me permettrez de douter de celui-ci.
Si cela ne vaut bien entendu pas vérité universelle et intemporelle, je
vais me permettre de m'en référer à mon expérience personnelle.
Je travaille dans le spatial, monde où deux logiques cohabitent :
* Sur les centres de contrôle, centres de missions et autres systèmes
opérationnels critiques, nous avons besoin de système stables,
qualifiés et maintenus sur le très long terme (plusieurs années
peuvent s'écouler entre le lancement d'une sonde et son activation en
vue de remplir la mission qui lui a été assignée). Les agences
spatiales optent donc pour des distributions adossées à des acteurs
commerciaux qui s'engagent contractuellement à ce support à très long
terme. Pendant longtemps, Sun a régné en maitre, avec son système
Solaris. Depuis dix ans, il a peu ou prou disparu au profit de
systèmes RHEL ou Suse.
* Sur les missions scientifiques, mais aussi sur les plateformes
opérationnelles de traitement et de distribution de données, nous
utilisons souvent des technologies, algorithmes, formats et protocoles
représentant l'état de l'art dans leur domaine. Certains d'entre eux
sont même développés pour les besoins de ces missions et sont
implantés dans des outils libres pour en favoriser l'adoption et la
dissémination. Les versions des bibliothèques fournies par une RHEL ou
même une Debian stable sont, à cette aune, antédiluviennes. Ce
faisant, le système de prédilection dans ce domaine est Ubuntu, non
à cause du système en lui-même et des bibliothèques fournies dans les
dépôts officiels de la distribution (les mêmes que dans Debian), mais
à cause des PPA, dans lesquels les mainteneurs de ces bibliothèques et
outils publient au plus tôt les dernières versions stables, voire les
versions « edge » de leur projet. La quasi-totalité de mes collègues
travaillant dans la télédétection, le traitement d'images optiques ou
radar ou la distribution des produits satellitaires dans leur forme
complexe, ont donc pour système de référence – imposé par leur client
– le système Ubuntu. L'outil doit fonctionner sur Ubuntu. Quant aux
autres plateformes, ça va du « hors-sujet » au « ce serait bien que ce
soit supporté, mais ce n'est pas une priorité ».
Et je parle bien là d'outils utilisés, pour certains, de manière
opérationnelle, sur des volumes de données colossaux et avec une
criticité assez élevée.
Bien sûr, comme partout ailleurs, cette logique est en train d'être
balayée par les déploiements autoportants que proposent les conteneurs
et les clusters Kubernetes. Ceci étant, l'image de base des conteneurs
utilisés dans ces domaines est souvent une Ubuntu.
> 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.
Le concept de cloisonnement, d'isolation, de partionnement, n'a pourtant
rien de neuf et il est prôné de longue date par les experts en sécurité.
La première forme historique de ce cloisonnement, très imparfaite, était
le « chroot », puis sont venues des technologies plus avancées (cgroups,
LXC, machines virtuelles, conteneurs Docker…). Partant du principe que
nous n'éliminerons jamais les bogues et failles de sécurité, l'isolation
est le sens de l'histoire.
> 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.
Ce n'est pas qu'un problème de ressources humaines, même si le manque de
personnes qualifiées l'accentue. Une fois encore, se coltiner toutes les
spécificités de chaque distribution, de chaque plateforme, n'a rien de
plaisant quand on est développeur et cela consomme un temps et une
énergie qui pourraient être bien mieux utilisées si la diversité de ces
plateformes était drastiquement réduite (sans qu'il soit souhaitable,
pour d'autres raisons, de ne disposer que d'un seul et unique système
d'exploitation). Même dans un contexte professionnel, il arrive qu'un
client revienne sur ses exigences initiales et nous demande de laisser
tomber le support de macOS ou d'une distribution GNU/Linux quelconque.
Au niveau des systèmes GNU/Linux, les efforts de standardisation que
sont la LSB et le FHS vont dans le bon sens, mais ces initiatives sont
une goutte d'eau dans l'océan de diversité qu'est le libre (pour ne
parler que de lui, car les systèmes d'exploitation propriétaires ont
bien d'autres tares).
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 !
Reply to: