Compilation de ART sous Fedora 35 classique ou variante :
(effectuée sous Fedora silverblue dans un container toolbox, sinon débuter aux prérequis pour classique) prérequis pour Fedora Silverblue ou Kinoite :
rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
toolbox create --container art --release f35
toolbox enter --container art
Bonjour, cela concerne essentiellement les versions Silverblue ou Kinoite de la Fedora car, sur ces distributions particulièrement sécurisées, il n’est possible d’installer une application que sous forme de flatpak ou dans un container toolbox. Je fais partie de ceux qui considèrent que l’avenir de linux passera probablement par ce type de solution très séduisante AMHA (troll inside)
L’objection de la place prise par des paquets contenant les dépendances date à mon avis de la période ou les disques étaient tout petits.
Sur W10, ce qui me prend le plus de place et de très loin, ce sont les photos et les videos (bien que depuis 2 ans je n’en fasse plus beaucoup !). La place occupée par les applis est marginale en comparaison.
Je ne m’étendrai pas sur l’intérêt de distribuer les applications sous forme de paquets Snapp, appimage ou flatpak. Il y a déjà eu des discussions assez chaudes là-dessus sur Pixls à propos de Displaycal .
Sous Windows le problème a été tranché depuis longtemps après le dll hell qui est une forme particulière à Windows du Dependency hell
Cependant avec l’arrivée des SSD, on se retrouve avec à nouveau un compromis taille/performance/prix, et souvent les SSD internes abordables mais performants restent de taille modeste (256/512 Go, là où les HDD classiques dépassent le téraoctet).
Juste mon expérience sur le sujet d’empaqueter les dépendances et la place occupée.
Oui, sur W10 j’utilise 3 disques, un SSD de 256GO pour le système (W10, WSL2 /Ubuntu), MSYS2 et les applis nécessitant une installation (en particulier les applis Linux que je ne sais pas mettre ailleurs), un HDD en ligne de 2TO pour les autres applis (toutes les applis de traitement d’image en particulier) et les données (mails, fichiers personnels, photos, videos…) et un HDD connecté en USB pour les archives que je connecte occasionnellement.
Bien que j’aie de multiples versions de ART, RT , DT et d’autres programmes (GIMP, filmulator…) que j’ai à un moment ou l’autre construit sous forme de paquets, je n’ai jamais identifié de problème d’occupation de disque.
Pour moi, l’utilisation de paquets ne créé aucun problème de place comparé aux photos, vidéos, diaporamas…
En tout cas pour W10, ce problème de place est un faux problème. Sur Linux, c’est peut-être un problème. Je n’ai pas assez d’expérience sur ce système.
Je voudrais insister sur le fait que la Fedora Silverblue est une distribution particulière, qualifiée d’immuable en ce sens que le système est totalement sécurisé car il est en lecture seule (inaccessible par mot de passe root). Il embarque ainsi le minimum de bibliothèques nécessaires à son fonctionnement, contrairement aux distributions classiques (rolling ou pas) qui sont souvent chargées de nombreuses applications avec leur bibliothèques.
On comprends, ici, tout l’intérêt des flatpaks qui, naturrellement sont lancés dans des bacs à sable, sans aucun accès possible au système.
Comme tu peux le voir @jpg54 cela n’a rien à voir avec windaube, véritable passoire. Certes, les flatpaks sont, par nature volumineux, mais comme l’ont justement dit @edmond_Gautier et @sguyader, il n’y a plus de pb de place sur nos gros DD. En terme de rapidité, c’est excellent.
Je pense que l’avenir de linux passera par ce genre de solution car il évite aux développeurs d’applications de tester toutes les distributions (avec leur bibliothèques différentes) ou aux distributions de gérer toutes les dépendances et de compiler : grosse simplification à tous les niveaux.
En plus Docker/Podman/Toolbox tourne de base sur cette fantastique distribution que j’ai adoptée sur mon portable principal.
Quand je compare à Windows, c’est pas en terme de sécurité et suis persuadé que ce système présente beaucoup plus de sécurité qu’un Linux classique qui est déjà très sécurité, c’est la multiplication des dépendances identiques mais à des niveaux de versions différents comme les Dll de Windows. J’ai utilisé Docker pour des tests de darktable et j’ai trouvé quand même les fichiers en dehors du contener.
Si un fournisseur de logiciel (FOSS ou payant) veut distribuer son logiciel sous forme de binaire et non sous forme de source à compiler localement, il est obligé de s’assurer qu’il fonctionnera bien sur la machine de l’utilisateur.
Les dépendances peuvent être incompatibles d’une version à la suivante (c’est d’ailleurs un travers des développeurs Linux dénoncé par Linus Torvalds). Le fournisseur est donc obligé d’empaqueter les dépendances avec le logiciel. D’où Appimage, Flatpak, Snap et autres qui répondent au problème du dependency hell.
Sous windows/MSYS2, il n’y a pas de dll de windows dans les paquets, seulement les dll générés par les développeurs de Msys2/Mingw64. Et pourtant ça fonctionne sur tous les Windows 64bits postérieurs à WXP!
Sous W10, le problème qui reste est que certaines applications veulent absolument s’installer et donc modifier le registre.
La séparation absolue système/applications me parait un progrès.
Je n’ai pas parlé des logiciels compilés sous MSYS2 qui utilise la sous-couche Linux/Ubuntu. D’ailleurs, je pense que Windows à plus ou moins cours deviendra une interface graphique cachant un Linux comme système d’exploitation, ça devrait remplacer l’utilisation des morceaux de systèmes d’exploitation donc NT2. AMHA
C’est pareil pour les logiciels compilés sous Visual C++. Les dépendances sont distribuées sous forme d’un package séparé VCredist à installer et qui existe en différentes versions.
Je pense qu’aucun fournisseur de logiciel n’installe actuellement des dll dans le système.
Je pense que WSL2 basé sur le Windows Hypervisor Platform permettant d’installer des environnements Linux natifs ne va pas dans ce sens. Je ne saurais en dire plus.
Plusieurs utilisateurs de darktable ont essayé de compiler pour Windows, je confirme qu’ils ont bien utiliser la couche Linux et produisent un .exe qui s’exécute parfaitement. J’ai plusieurs fois essayé sans réussir, il doit manquer quelque chose sur ma marchine.
Si on utilise MSYS2/mingw64 pour construire un application pour Windows il n’y a pas de noyau linux utilise. Tous les utilitaires msys et mingw64, les programmes generes et les dependances sont natifs windows. L’environnement linux est simulé par Msys et on peut executer les bash developpes sous une distribution linux.
J’ai fait il y a 4 ou 5 ans des builds de dt sous msys qui s’exécutaient sans problème sous windows.
On peut cross compiler avec linux/mingw64 des programmes natifs pour windows.
Je crois d’ailleurs que msys2 et mingw64 sont generes sous archlinux avec pkgbuild.
