Une distribution linux ? Oui, mais laquelle ?

C’est pour ça que Flatpak ne concerne que des applications graphiques, par conception.

Du coup ça permet une autre approche du système d’exploitation qu’incarne par exemple Fedora Silverblue.

Un OS de base très minimal en lecture seule, que tu mets à jour comme un ensemble cohérent (en gros tu migres d’un état complet à un autre). Cela rend le système très stable et facile à maintenir : peu de risques que ta machine ne boot pas du tout.

Des conteneurs applicatifs simplifiés avec Fedora toolbox par exemple : tu as un projet de développement en Python 3.5 ? Tu instancies un système qui fait le setup interne avec les outils qu’il faut pour ton travail. Quand tu as fini c’est facile de le virer entièrement, si tu veux en parallèle bosser avec Python 3.10, PHP 8.2 et PHP 7.5, etc. pas de soucis à gérer ou de prise de tête avec des environnements virtuels propres à chaque écosystème.

Les applications graphiques usuelles qui sont dans des bacs à sable et dont tu peux gérer finement les permissions à la volée ou pas comme tu peux trouver sur téléphone. Là encore cela devient trivial d’installer en parallèle plusieurs versions d’un même logiciel, de prendre la dernière version dispo même si ta distro ne la propose pas, de t’assurer que Firefox ne va pas par accident supprimer ta thèse sur le disque ou l’envoyer spontanément à la NSA.

Question perf, j’ai entendu beaucoup de mal de Snap à ce sujet, je n’ai pas testé et je ne peux pas dire. Niveau Flatpak je ne le ressens pas pour des applications allant du jeux vidéo, à Slack ou Libreoffice donc ça me semble correct. Il n’y a pas de raisons que les performances soient drastiquement affaiblies, si les téléphones et Windows 10 / macOS arrivent à faire des bacs à sable propre, que les conteneurs et machines virtuelles peuvent être presque transparents dans de nombreux cas d’usage, je ne vois pas pourquoi ce serait un vrai frein. Mais si Snap n’y arrive pas aujourd’hui, cela peut être différent demain.

C’est pour ça que Flatpak ne concerne que des applications graphiques, par conception.

Ça rend la stratégie d’utiliser des conteneurs pour maintenir un système à jour impossible (ainsi que pour les plupart des points que tu soulèves dans le reste de ton message). Perso j’utilise pas beaucoup d’applications graphiques, quand je parle d’avoir un système à jour ce sont les libs et le tooling dont je parle.

Un OS de base très minimal en lecture seule, que tu mets à jour comme un ensemble cohérent (en gros tu migres d’un état complet à un autre). Cela rend le système très stable et facile à maintenir : peu de risques que ta machine ne boot pas du tout.

T’as fonctionnellement exactement la même chose avec une rolling-release comme Arch, sauf que tu mets à jour composant par composant… T’as toujours un seul ensemble de paquet qui est supporté et valide, ce qui évite toute la complexité nécessaire par exemple dans apt pour gérer plein de versions des paquets.

Des conteneurs applicatifs simplifiés avec Fedora toolbox par exemple : tu as un projet de développement en Python 3.5 ? Tu instancies un système qui fait le setup interne avec les outils qu’il faut pour ton travail. Quand tu as fini c’est facile de le virer entièrement, si tu veux en parallèle bosser avec Python 3.10, PHP 8.2 et PHP 7.5, etc. pas de soucis à gérer ou de prise de tête avec des environnements virtuels propres à chaque écosystème.

Si on limite les conteneurs aux applications graphiques, on ne peut pas faire ça. Par ailleurs on n’a certainement pas besoin d’avoir des conteneurs pour avoir plusieurs versions d’une librairie ou d’un langage à la fois. Les systèmes à la lmod par exemple ça existe depuis bien plus longtemps que docker et autre consorts. Choisir des conteneurs ou choisir lmod pour gérer ça, c’est une question orthogonale à la question de savoir si les conteneurs généralisés pour tout sont une bonne stratégie. Ce que les conteneurs résolvent bien est le problème de construire des environnement très complexes facilement et d’avoir des matrices de dépendances, mais c’est pas tellement un besoin sur un PC. C’est un problème de serveur CI par exemple.

de prendre la dernière version dispo même si ta distro ne la propose pas

Encore faut il que tu ais un conteneur prêt pour ce logiciel. Ça déplace juste le problème de qui te fournit le paquet/le conteneur.

de t’assurer que Firefox ne va pas par accident supprimer ta thèse sur le disque ou l’envoyer spontanément à la NSA

Si on en est à considérer sérieusement ce niveau d’attaque, on peut surtout commencer à s’inquiéter des trous de sécurité dans le matériel, l’OS et le conteneur lui même, parce que c’est pas utiliser encore une couche avec un système de permissions qui va magiquement les corriger. Si on parle plus raisonnablement de se protéger contre des bugs via des garde-fous supplémentaires sur les permissions, c’est à peu près le seul avantage réel des conteneurs que je vois, mais il est tout de même plutôt faiblard compte tenu de la lourdeur du design général.

Il n’y a pas de raisons que les performances soient drastiquement affaiblies

Ben euh si, il y a une raison assez évidente : tu ne peux pas à la fois profiter e.g. des instructions processeurs propres à une architecture donnée et livrer un binaire qui tourne partout (et c’est encore pire si tu commences à considérer les instructions propres au matériel sur lequel tu tournes effectivement qui vont te demander de compiler à la main et certainement pas de wrapper ça dans un conteneur). Quand on parle de livrer un programme graphique, on s’en fout pas mal tant qu’il ne fait rien de CPU-intensif. Si on parle de livrer une lib de calcul, ça devient plus embêtant.

Tu peux te contenter de mises à jour importantes d’Ubuntu tous les deux ans en fait, de LTS en LTS – ça fonctionne très bien. Le reste c’est les mises à jour de sécurité et de bugs critiques si tu veux. Et donc, ça veut dire 2 h de mise à jour à planifier une fois tous les deux ans, ça va.

Personnellement j’avais commencé sur une non-LTS mais uniquement parce que mon matériel dernier cri n’était pas encore supporté par Ubuntu 18.04 qui était la dernière LTS disponible.

Sinon, un gros +1 à Renault sur l’intérêt des snaps/flatpack/etc. Je rajoute que les versions de base (et encore actuelles) sont parties sur une très mauvaise image par manque d’intégration au reste de l’OS, en particulier avec le thème (un « détail » mais ultra visible) ou les permissions. Mais sinon, malgré la surconsommation en ressources et d’autres problèmes intrinsèques, ça a énormément d’avantages, entre autres celui de la sécurité si c’est bien fait. Ça permet entre autres de répondre à cette vieille blague :

Contrairement à Windows (il y a longtemps), les comptes utilisateur Linux ne sont pas admin par défaut. Ça veut dire que si je me fais corrompre mon navigateur et qu’un site peut lancer des sites arbitraires, il ne peut pas installer de pilote ou de composant dans mon OS. Il n’a accès que ce à quoi à accès mon compte utilisateur, c’est-à-dire seulement mon historique de navigation, mes comptes, mes mails, mes documents…

Cela dit, c’est une problématique intéressante sur le desktop, je reste beaucoup moins convaincu sur serveur, surtout aujourd’hui où on est soit dans des environnements bien maitrisés (les serveurs de calcul, etc.) soit dans du cloud où chaque programme terminal est très isolé du reste, typiquement à coup de Docker, Kubernetes et compagnie. Les serveurs avec tout installé en vrac et donc où la moindre faille met en danger toute la pile, c’est de plus en plus rare.

Bien que je prenne le temps de faire marcher mon matériel sous Linux (typiquement quand je change de PC portable), je n’ai pas de temps pour la maintenance si ça casse. En conséquence, je joue la stabilité. J’étais sur une Ubuntu LTS 18.04 jusqu’à l’année dernière où je suis passé sur la 20.04, et je changerais probablement pour celle d’après l’année prochaine.

Niveau mise à niveau entre deux LTS, c’est essentiellement transparent. Rien n’a changé pour mon usage et à chaque fois, ça a été opérationnel immédiatement sans casser mon workflow. Très court, une paire d’heures je dirais.

Ce que je gagne, c’est en stabilité. Je compte plus le nombre de fois où j’entends des gens dire « non mais XYZ ça marche » et oublier la fois où ils ont passé deux plombes à comprendre leur soucis de son, wifi, etc. à cause de la mise à jour du noyau qui a cassé un driver (ce qui est impossible à deviner a priori, surtout si le soucis apparaît longtemps après au gré d’un redémarrage). Bref, rolling release c’est super tant que c’est pas le noyau qu’on touche. Si tu as ce contrôle, ça va.

Après, sur l’âge des paquets dans une LTS, ce n’est pas vraiment un soucis en pratique. Si j’ai envie de la dernière version de quelque chose, je l’installe en standalone et je l’oublie jusqu’à temps que j’ai envie de la nouvelle version. Ça veut en général dire que c’est un logiciel important pour moi et je peux bien passer 5 min à le mettre dans /opt/ et faire un .desktop s’il n’est pas fourni avec. La liste à tendance à s’allonger, mais ça se compte sur les doigts des deux mains. Il y a de toute façon des logiciels pour lesquels je n’ai pas le choix, ils ne sont pas dans les dépôts de quiconque.

On parle de snap, la dernière fois que j’ai essayé c’était une catastrophe pour un usage desktop (un dossier ~/snap qui pollue sans possibilité de le bouger, les logiciels lents à démarrer, les logiciels qui marchent pas vraiment parce qu’il faut s’amuser à configurer des permissions pour qu’ils puissent juste faire la chose élémentaire pour laquelle ils sont faites, l’embrouille dans les menus entre les versions snap et pas snap, et j’en oublie peut-être). Bref, c’est sûrement mieux maintenant, mais c’était pas très mature et on le forçait un peu trop sur les utilisateurs pour un usage pour lequel il n’étaient pas vraiment pensés. J’ai eu une meilleure expérience avec Flatpak ; j’ai eu l’occasion d’utiliser pour certaines choses.

Je précise au cas où que archlinus propose des noyaux LTS, et des drivers LTS (de cartes graphiques, notamment)

C’est pour ça que Flatpak ne concerne que des applications graphiques, par conception.

Ça rend la stratégie d’utiliser des conteneurs pour maintenir un système à jour impossible (ainsi que pour les plupart des points que tu soulèves dans le reste de ton message). Perso j’utilise pas beaucoup d’applications graphiques, quand je parle d’avoir un système à jour ce sont les libs et le tooling dont je parle.

En quoi c’est impossible ? Cela se fait très bien. D’autant plus que Flatpak a le concept des runtimes pour partager des bibliothèques communes pour limiter les ressources consommées (espace disque, mémoire) et simplifier la maintenance.

Après oui, tu ne peux pas tout avoir, c’est évident, mais on ne peut pas dire que la situation actuelle soit parfaite non plus. Entre la difficulté de la gestion des dépendances, les bogues liés au fait de partager une bibliothèque unique à toutes les apps pas forcément bien testées pour cette version, l’absence totale de granularité dans la sécurité applicative, le processus de mise à jour relativement peu fiable…

Un OS de base très minimal en lecture seule, que tu mets à jour comme un ensemble cohérent (en gros tu migres d’un état complet à un autre). Cela rend le système très stable et facile à maintenir : peu de risques que ta machine ne boot pas du tout.

T’as fonctionnellement exactement la même chose avec une rolling-release comme Arch, sauf que tu mets à jour composant par composant… T’as toujours un seul ensemble de paquet qui est supporté et valide, ce qui évite toute la complexité nécessaire par exemple dans apt pour gérer plein de versions des paquets.

Pas tout à fait. L’idée dans Silverblue c’est que l’OS de base c’est en gros le noyau, le chargeur de démarrage, systemd, glibc, un shell, de quoi avoir du réseau, les outils vraiment basiques du système pour démarrer et l’environnement de bureau de ton choix sans les applicatifs. C’est vraiment minimal pour être capable de démarrer un système et de le sauver si nécessaire.

L’avantage c’est que cela fonctionne par état, comme on dit sous forme de "git des binaires". Chaque état est un commit.

L’avantage est multiple par rapport à ce que ArchLinux ou les autres distributions font sur cet aspect :

• La mise à jour est faite à froid et est instantanée (donc plus fiable, moins de risques de bogues) ;
• La sauvegarde de l’état précédent est trivial, en cas de problème tu peux redémarrer sur l’ancien état et avoir ton système qui démarrait dans tous les cas sans repose sur un système de fichiers en particulier ;
• L’ordre des opérations est connu et figé, l’état du système aussi. Pas de risque que libmachin a été mis à jour avant libbidule sur le poste 1, mais l’inverse dans le poste 2 ou encore qu’un poste a eu la mise à jour de libbidule mais pas de libmachin car le miroir s’est synchronisé au mauvais moment. Car en fait tout est mis à jour ensemble de manière atomique ;
• Une coupure de courant ou un plantage de système en pleine mise à jour ne pose aucun problème quelconque, car ton état courant reste fonctionnel et identique ;
• Remettre à un système à 0 tout en le laissant fonctionnel (revente de l’ordinateur, fin de contrat avec l’employeur, autres) est une opération aussi triviale ;
• Les tests de l’image système fournis sont aussi bien plus simples, comme l’état est connu et figé, ta batterie de tests sera conforme pour tout le monde. Cela évite les tests qui malheureusement ne peuvent prendre en compte les personnalisations de chacun et le fait que certaines opérations ne sont pas déterministes.

Des conteneurs applicatifs simplifiés avec Fedora toolbox par exemple : tu as un projet de développement en Python 3.5 ? Tu instancies un système qui fait le setup interne avec les outils qu’il faut pour ton travail. Quand tu as fini c’est facile de le virer entièrement, si tu veux en parallèle bosser avec Python 3.10, PHP 8.2 et PHP 7.5, etc. pas de soucis à gérer ou de prise de tête avec des environnements virtuels propres à chaque écosystème.

Si on limite les conteneurs aux applications graphiques, on ne peut pas faire ça.

Je ne comprends pas ce que tu veux dire, Fedora toolbox et les Flatpak sont complémentaires.

Par ailleurs on n’a certainement pas besoin d’avoir des conteneurs pour avoir plusieurs versions d’une librairie ou d’un langage à la fois. Les systèmes à la lmod par exemple ça existe depuis bien plus longtemps que docker et autre consorts. Choisir des conteneurs ou choisir lmod pour gérer ça, c’est une question orthogonale à la question de savoir si les conteneurs généralisés pour tout sont une bonne stratégie.

Oui, et ? Où tu veux en venir ? Je te montre le concept général et l’approche envisagée, pas que c’était l’unique solution.

de prendre la dernière version dispo même si ta distro ne la propose pas

Encore faut il que tu ais un conteneur prêt pour ce logiciel. Ça déplace juste le problème de qui te fournit le paquet/le conteneur.

Fedora automatise pour justement que la création d’un RPM construire automatiquement le Flatpak dédié. Tu as plus de chance que le développeur principal de l’application fasse un livrable utilisable partout que de faire un paquet qui ne fonctionnera que sur une variante, ou de se mettre à faire un paquet par format et essayer d’être compatible avec tout le monde à la main.

de t’assurer que Firefox ne va pas par accident supprimer ta thèse sur le disque ou l’envoyer spontanément à la NSA

Si on en est à considérer sérieusement ce niveau d’attaque, on peut surtout commencer à s’inquiéter des trous de sécurité dans le matériel, l’OS et le conteneur lui même, parce que c’est pas utiliser encore une couche avec un système de permissions qui va magiquement les corriger. Si on parle plus raisonnablement de se protéger contre des bugs via des garde-fous supplémentaires sur les permissions, c’est à peu près le seul avantage réel des conteneurs que je vois, mais il est tout de même plutôt faiblard compte tenu de la lourdeur du design général.

Tu trouves cela négligeable, moi pas.

Exemple typique, j’utilise dans le cadre pro Slack et Skype. Cela m’est imposé. Applications proprio, je n’ai pas spécialement confiance dans les éditeurs. Ils sont installés via Flatpak et n’ont accès qu’au strict minimum. En cas de bugs, de faille de sécurité ou de comportement nuisible je suis bien plus sûr qu’ils ne toucheront pas à mes données sensibles que si j’utilise Firefox nu (version web de ces applications) ou sans Flatpak.

Et au moins pour la compatibilité pas besoin d’un dépôt spécial compatible avec ma version de Fedora (j’utilise en plus souvent des versions de développement), juste besoin que quelqu’un propose un tel livrable pour tout le monde ce que Flathub fait très bien.

Dans un contexte où les gens installent parfois des applications dont la provenance est peu sûre, limiter les accès me semble être une bonne pratique par défaut.

Il n’y a pas de raisons que les performances soient drastiquement affaiblies

Ben euh si, il y a une raison assez évidente : tu ne peux pas à la fois profiter e.g. des instructions processeurs propres à une architecture donnée et livrer un binaire qui tourne partout (et c’est encore pire si tu commences à considérer les instructions propres au matériel sur lequel tu tournes effectivement qui vont te demander de compiler à la main et certainement pas de wrapper ça dans un conteneur). Quand on parle de livrer un programme graphique, on s’en fout pas mal tant qu’il ne fait rien de CPU-intensif. Si on parle de livrer une lib de calcul, ça devient plus embêtant.

Pour moi tu mélanges pas mal de choses.

Déjà la différence sur ce point avec une distro classique est faible. Le Firefox x86_64 bits que Fedora propose est le même pour tout le monde. Il est compilé avec les mêmes options et n’est pas spécialement optimisé pour mon modèle de processeur. Et souvent les distributions sont plutôt conservatrices pour éviter les soucis de compatibilités avec la plupart des utilisateurs. C’est après tout une distribution binaire, si on veut personnaliser pour son processeur, c’est vers Gentoo qu’il faut regarder.

Ensuite, rien ne t’empêche de faire ta lib optimisée de la mort pour ton processeur ou ton serveur de calcul et fournir cela avec un conteneur ou une image Flatpak (si c’est utilisé dans une application graphique), le format est universel mais comme tout binaire si ton processeur ne gère pas des instructions, ça ne fonctionnera effectivement pas. Mais rien ne t’empêche de limiter la compatibilité matérielle si tu souhaites fournir tout cela à des machines bien précises.

C’est juste un livrable, tu es tout à fait libre de faire ce que tu veux avec après.

Par ailleurs, je ne crois pas que Flatpak ou Snap vont conquérir le monde et que l’ancien monde n’existera plus. Fedora Silverblue c’est une expérience d’une vision, ils évaluent justement la faisabilité et le cadre de pertinence. Peut être que ce sera la version de référence chez Fedora un jour, peut être pas. Peut être que les distributions bureautiques adopteront massivement tout cela, peut être pas, peut être que le monde des serveurs suivra, ou pas du tout. Et s’il y a des gens pas contents, rien n’empêchera de faire une Gentoo pour tout refaire à sa sauce à partir des sources.

Pour revenir sur le sujet de base, personnellement, je conseille de partir sur Archlinux si tu as envie de faire du Archlinux, de passer les heures qu’il y a à passer sur le wiki pour l’installation. Si tu t’interroges, j’aurais tendance à déconseiller. Sinon, Ubuntu, Fedora, Linux Mint, un peu même combat. Choisir le système qui s’intègre le mieux avec l’environnement de bureau que tu veux utiliser, et qui propose ce que tu veux en logiciels. Par exemple, beaucoup de logiciels ne supportent officiellement qu’Ubuntu, par exemple Steam et tous les jeux qu’ils portent via Proton.