Bastien TraverseJe suis profondément las que #Windows soit la cible de développement par défaut pour les fournisseurs de logiciels, et en même temps, outre que c'est là où le marché est (du fait des pratiques anticoncurrentielles honteuses de #Microsoft), quand je vois la fragmentation de l'écosystème #GNU/#Linux et la difficulté, même pour des gens expérimentés, de répondre à la simple question "quelle distribution recommander au grand public", alors je me dis qu'il pourrait difficilement en être autrement.
Alors bien sûr, il est toujours possible de dire pour ces fournisseurs de logiciels "Nous ciblons telle #distribution dans telle version", et c'est ce que beaucoup font. Mais pour atteindre une masse critique d'utilisateurs, en général ils sont obligés de cibler 2 à 5 distributions, et donc de s'acculturer aux spécificités de chacune : cycle de vie, format de paquet, comment interagir avec les mainteneurs... En pratique ils se retrouvent à supporter 2 à 5 OS supplémentaires au lieu de 1.
Avec la montée en force d'#Ubuntu dans les années 2010, cette situation s'est quelque peu améliorée : certains vendeurs sentent qu'il est suffisant de proposer leur logiciel sur "Ubuntu XX.YY" pour atteindre la majorité des utilisateurs potentiels. J'en ai eu comme ça en formation, des gens qui venaient découvrir Ubuntu uniquement pour pouvoir utiliser leur logiciel de calcul scientifique.
Quand ce n'est pas Ubuntu alors généralement c'est un clone de #RedHat, #CentOS en tête. Ça a mal fini...
La véritable solution réside dans les systèmes de distribution d'applications interopérables : plus besoin de cibler un OS et une version spécifiques, on peut juste cibler la plateforme de distribution. Ce sont les #flatpak, #snap et autres #appimage de ce monde.
Malheureusement, elles ont toutes des limitations importantes :
- flatpak est limité aux applications graphiques : impossible de distribuer une CLI avec
- snap est le pré carré de #Canonical, et souffre de sa mauvaise réputation
- ...
- ...AppImage n'a pas de mécanisme de mise à jour intégré, se contentant de reproduire sur Linux les "app bundles" de Mac, et présente une forme de retour en arrière dans la distribution de logiciel puisqu'il reproduit la jungle sauvage de téléchargement d'exécutables que l'on connaît sous Windows.
En parallèle, les années 2010 ont vu la révolution des #conteneurs applicatifs : #Docker présente un mécanisme standardisé pour empaqueter, distribuer et exécuter une application, qui peut être...
... une CLI (le plus fréquent) mais aussi graphique.
Alors, pourquoi les conteneurs applicatifs n'ont pas encore remplacé les autres méthodes de distribution de logiciels ?
Et bien déjà, il faut comprendre qu'un conteneur applicatif embarque souvent des petits morceaux d'une distribution, juste ce qui est nécessaire pour faire tourner l'appli. Il faut donc à nouveau choisir entre Debian, Ubuntu, Alpine ou l'une des substitutions (distroless etc.).
Ensuite, Docker reste plus complexe que...
... les systèmes précédemment décrits : on ne peut pas juste double-cliquer sur un fichier et avoir notre programme qui s'ouvre.
La conteneurisation crée une barrière technique (montage de volumes, accès au serveur graphique...) qui n'est pas triviale ; malgré cela, on peut dire que Docker a phagocyté les Snap pour les applications en ligne de commande : la plupart des projets fournissent un conteneur et un fichier Compose pour une consomma facilitée.
Mais ça reste tourné "applicatifs...
... métier", et pas spécialement grand public.
Donc on en est là, avec au moins 4 approches concurrentes, des distributions toujours aussi fragmentées et dissemblables, et pas plus de clarté pour les fournisseurs de logiciel qui souhaiteraient cibler GNU/Linux.
À ma connaissance, le projet qui essaye le plus d'avancer sur ce sujet de l'obtention facilitée d'applications interopérables est https://github.com/ublue-os. Ils utilisent même des conteneurs pour composer l'OS !
