J'ai pourtant eu l'impression qu'il y a encore pas mal de gens qui apprécient ces systèmes plein d'artifices
Mais ce sont donc des personnes qui ne participent pas par le portage du coup ?
Mon expérience est forcément limitée à... mon expérience (haha), donc avec plein de biais. Mais j’ai également l’impression qu’il y a encore pas mal de gens qui apprécient ces systèmes (macOS), mais je ne vois que des personnes qui ne participent pas par le portage.
Je vois surtout des gens réclamer. Pour NetRadiant et pour XQF c’est pareil. De temps en temps quelqu’un passe et demande « quand est-ce qu’il y aura un binaire macOS ? » et voilà c’est tout. Maintenant que j’ai énormément bossé la compilation pour Windows et pour macOS au profit de NetRadiant et que j’ai déchargé ma connaissance dans des outils que j’ai écrit, peut-être que je pourrai utiliser les mêmes outils pour porter XQF, mais ce serait vraiment par chance parce qu’à cause d’un autre projet j’ai dû bosser cela. Pour Unvanquished c’est comme si on en avait toujours eu un binaire macOS, donc je n’ai pas vu des gens réclamer un portage, par contre je sais que personne dans l’équipe de développement ne développe pour macOS. Historiquement, une des têtes du projet (la direction est un triumvirat) avait un ordinateur financé par un tiers dans un autre cadre, et dans cet autre cadre il réclamait systématiquement un mac pour une seule raison : l’intention de garder macOS en double-boot pouvoir compiler Unvanquished pour macOS à l’occasion. Nous avons en fait un collaborateur qui utilise macOS mais il ne contribue pas de code et ne contribue pas au portage.
Je vais même dire, certaines personnes qui réclament un portage macOS pendant plusieurs années sans se décourager n’utilisent même pas macOS sur des macs, mais sur des hackintosh, c’est dire à quel point c’est ingrat. Je fais en partie le portage de NetRadiant pour macOS pour des utilisateurs de macOS qui montent eux-même leur bécanes et pourraient tout aussi bien utiliser Linux.
Que ce soit pour Unvanquished, NetRadiant, XQF et d’autres outils, en 10 ans, je n’ai jamais eu à faire la revue d’un contributeur de code macOS réalisé par un utilisateur de macOS.
Une exception que j’ai relevée, c’est l’outil Crunch qui sert à convertir des images vers un format optimisé pour les cartes graphiques. Historiquement je me suis préoccupé de ce que la bibliothèque embarquable compile et tourne sous macOS à cause de NetRadiant (pour pouvoir lire dans NetRadiant les fichiers produits) mais je sais que l’outil de conversion ne compile pas pour macOS. J’ai récemment identifié un fork de quelqu’un qui ne nous a jamais contacté et qui semble être un développeur de jeu pour iPhones travaillant sous macOS et qui semble donc avoir terminé le portage. Un jour je fusionnerai ses patchs, et ce sera la première fois de ma vie que je fusionnerai un patch de portage macOS réalisé par un utilisateur de macOS pour son propre usage, la première fois en 10 ans et une poignée de projet, et de la part de quelqu’un qui ne contribue pas à nos projets ni ne nous a jamais contacté et ne partage pas nos intérêts à part produire des fichiers images optimisés pour GPU, il ne s’agit pas de contribuer à Unvanquished, le moteur Dæmon, NetRadiant ou autre logiciel libre que moi ou certains lecteurs de LinuxFr pourraient vouloir utiliser directement.
En comparaison, un développeur d’Unvanquished et du moteur Dæmon qui a un des plus haut taux de contribution et de compétence réunis utilise Windows et Visual Studio comme environnement de développement principal, autant dire que non-seulement Windows est pris en charge, mais même ce dont ont peut se passer est pris en charge. Pour NetRadiant je ne me soucie que de la compatibilité MSYS2 à-la-Linux, parce c’est tout ce dont j’ai besoin, mais pour Unvanquished et Dæmon, je sais qu’un contributeur peut tout faire avec la méthode Microsoft, on est au delà du nécessaire.
Pour Unvanquished et macOS ? Eh bien... le moteur compile et le jeu tourne, c’est tout. Je dis bien que seul le moteur de jeu Dæmon. Depuis deux ou trois ans, il n’est plus possible de compiler le code du jeu pour une raison que personne n’a vraiment investigué. Cela ne nous pose pas problème puisqu’avec la technologie NativeClient qu’on utilise encore, les binaires du jeu exécutés par le moteur sont indépendant du système d’exploitation (pour faire une analogie, c’est comme avoir un binaire java proprement fait qui est sensé tourner sur la JVM dès lors que la JVM est portée sur une plateforme), donc on compile le code du jeu une fois pour toute sur un système pris en charge (comme Linux), et puis après on compile les binaires du moteur pour Linux, Windows et macOS. Personne n’a jamais tenté de corriger la compilation du « game code » sous macOS, on a reçu des réclamations mais personne pour ne serait-ce qu’identifier ce qui ne marche pas et faire un rapport plus détaillé que « ça ne marche pas ». Il est probable que ce soit lié à l’abandon du 32-bit par macOS car si on produit des binaires indépendant du système d’exploitation, pour le moment on produit toujours une spécialisation i686/amd64 (ça devrait être corrigé avec WebAssembly, on est en train de migrer de NaCl vers Wasm).
Porter des logiciels sous macOS est très ingrat sur plein d’aspects, déjà les utilisateurs qui se manifestent sont vraiment, vraiment, vraiment rares, de deux, ils ne contribuent pas du portage, de trois, ils n’utilisent peut-être même pas de mac fabriqué par Apple ! C’est à se demander pourquoi faire tant d’efforts.
Je me souviens quand il était difficile de trouver des contributeurs Windows, je me souvient que GIMP souffrait beaucoup avec Windows d’une situation similaire à ce que GIMP souffre aujourd’hui avec macOS. Je me souviens aussi quand Darktable ne fournissait pas de binaires Windows, quand j’ai lu la première annoncé de WSL (Windows Subsystem for Linux) j’ai tout de suite pensé que ce serait une excellente manière de faire tourner Darktable sous Windows, mais en fait Darktable est arrivé en natif sous Windows presque en même temps que WSL.
Mais pour Windows, non seulement on semble désormais trouver plus (+) de développeurs, mais
on peut faire de la cross-compilation sous Linux et tester avec Wine;
MSYS2/MingW fonctionne très bien sous Windows;
une licence Windows 10 PRO coûte 10€ sur Amazon, le double boot se fait depuis toujours;
la virtualisation de Windows est très aisée sous Linux;
le fait de compiler un dépôt git sur un disque réseau depuis une machine virtuelle Windows fonctionne très bien;
la disponibilité de Mesa sous Windows et de son émulation logicielle (llvmpipe) rend très aisée le test de composants graphiques OpenGL avec une prise en charge complète même sans pass-through.
Pour macOS:
il n’y a pas encore de cross-compilation fonctionnelle, ni de couche de compatibilité pour Linux fonctionnelle, un jour Darling peut-être ? (hu, le certificat est expiré);
officiellement la seule méthode pour développer sous macOS consiste à acquérir un matériel Apple, et ça coûte plus cher qu’une licence Windows ou Linux (haha).
l’installation de macOS sur du matériel non-apple n’est pas aisée, et ce n’est pas sensé être fait;
la virtualisation de macOS n’est pas aisée (même si ça a été grandement simplifié via ce projet OSX-KVM), et ce n’est pas sensé être fait;
les performances de compilation d’un dépôt git sur un disque réseau depuis une machine virtuelle sont désastreuse, avec SSHFS (non officiel) sur FUSE pour mac, on rencontre facilement des crash nécessitant de rebooter et certaines fonctionnalités de système de fichier ne sont pas implémentées, avec le pilote smbfs natif de macOS c’est un gel systématique de l’OS qui se produit en moins de deux minutes;
l’émulation logicielle d’OpenGL sous macOS semble ne pas dépasser OpenGL 2.1 (donc pré-OpenGL core).
Un utilisateur de logiciel gratuit qui demande un portage pour macOS réclame que le développeur achète un mac et travaille sur mac comme environnement de développement, comme ça, gratos, rien de moins.
Pour un éditeur de logiciel payant, ceci peut n’être considéré que comme des achats de fournitures particulières, peut-être moins chères que certains logiciels, mais pour un contributeur bénévole de logiciel gratuit, le coût de développement pour macOS est énorme.
Donc bref, bravo à GIMP et Jehan d’être si généreux 👍, je ne doute pas que de tels efforts sont remerciés par beaucoup d’ingratitude, à commencer par « même pas un merci ». 😏
Message spécial à Jehan : l’intégration des « Pipelines » Microsoft Azure est plutôt efficace avec GitHub et prend désormais en charge macOS (exemple) donc tu peux éventuellement envisager de « profiter du système » en poussant un clone du dépôt GIMP de git sur GitHub et de pousser ta branche de développement macOS sur github pour valider la compilation gratuitement à chaque push de commit. Après tu reviendras à ta solution actuelle pour produire le binaire distribuable. Alors GitHub, Azure, tout ça oui c’est pas très « logiciel libre » mais bon il s’agit de produire un binaire macOS à la base... C’est déjà très très très sale. 😜
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: activité lente, sinon moribonde du côté de macOS...
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Sortie de GIMP 2.10.28 et nouvelles autour du projet. Évalué à 10.
Mon expérience est forcément limitée à... mon expérience (haha), donc avec plein de biais. Mais j’ai également l’impression qu’il y a encore pas mal de gens qui apprécient ces systèmes (macOS), mais je ne vois que des personnes qui ne participent pas par le portage.
Je vois surtout des gens réclamer. Pour NetRadiant et pour XQF c’est pareil. De temps en temps quelqu’un passe et demande « quand est-ce qu’il y aura un binaire macOS ? » et voilà c’est tout. Maintenant que j’ai énormément bossé la compilation pour Windows et pour macOS au profit de NetRadiant et que j’ai déchargé ma connaissance dans des outils que j’ai écrit, peut-être que je pourrai utiliser les mêmes outils pour porter XQF, mais ce serait vraiment par chance parce qu’à cause d’un autre projet j’ai dû bosser cela. Pour Unvanquished c’est comme si on en avait toujours eu un binaire macOS, donc je n’ai pas vu des gens réclamer un portage, par contre je sais que personne dans l’équipe de développement ne développe pour macOS. Historiquement, une des têtes du projet (la direction est un triumvirat) avait un ordinateur financé par un tiers dans un autre cadre, et dans cet autre cadre il réclamait systématiquement un mac pour une seule raison : l’intention de garder macOS en double-boot pouvoir compiler Unvanquished pour macOS à l’occasion. Nous avons en fait un collaborateur qui utilise macOS mais il ne contribue pas de code et ne contribue pas au portage.
Je vais même dire, certaines personnes qui réclament un portage macOS pendant plusieurs années sans se décourager n’utilisent même pas macOS sur des macs, mais sur des hackintosh, c’est dire à quel point c’est ingrat. Je fais en partie le portage de NetRadiant pour macOS pour des utilisateurs de macOS qui montent eux-même leur bécanes et pourraient tout aussi bien utiliser Linux.
Que ce soit pour Unvanquished, NetRadiant, XQF et d’autres outils, en 10 ans, je n’ai jamais eu à faire la revue d’un contributeur de code macOS réalisé par un utilisateur de macOS.
Une exception que j’ai relevée, c’est l’outil Crunch qui sert à convertir des images vers un format optimisé pour les cartes graphiques. Historiquement je me suis préoccupé de ce que la bibliothèque embarquable compile et tourne sous macOS à cause de NetRadiant (pour pouvoir lire dans NetRadiant les fichiers produits) mais je sais que l’outil de conversion ne compile pas pour macOS. J’ai récemment identifié un fork de quelqu’un qui ne nous a jamais contacté et qui semble être un développeur de jeu pour iPhones travaillant sous macOS et qui semble donc avoir terminé le portage. Un jour je fusionnerai ses patchs, et ce sera la première fois de ma vie que je fusionnerai un patch de portage macOS réalisé par un utilisateur de macOS pour son propre usage, la première fois en 10 ans et une poignée de projet, et de la part de quelqu’un qui ne contribue pas à nos projets ni ne nous a jamais contacté et ne partage pas nos intérêts à part produire des fichiers images optimisés pour GPU, il ne s’agit pas de contribuer à Unvanquished, le moteur Dæmon, NetRadiant ou autre logiciel libre que moi ou certains lecteurs de LinuxFr pourraient vouloir utiliser directement.
En comparaison, un développeur d’Unvanquished et du moteur Dæmon qui a un des plus haut taux de contribution et de compétence réunis utilise Windows et Visual Studio comme environnement de développement principal, autant dire que non-seulement Windows est pris en charge, mais même ce dont ont peut se passer est pris en charge. Pour NetRadiant je ne me soucie que de la compatibilité MSYS2 à-la-Linux, parce c’est tout ce dont j’ai besoin, mais pour Unvanquished et Dæmon, je sais qu’un contributeur peut tout faire avec la méthode Microsoft, on est au delà du nécessaire.
Pour Unvanquished et macOS ? Eh bien... le moteur compile et le jeu tourne, c’est tout. Je dis bien que seul le moteur de jeu Dæmon. Depuis deux ou trois ans, il n’est plus possible de compiler le code du jeu pour une raison que personne n’a vraiment investigué. Cela ne nous pose pas problème puisqu’avec la technologie NativeClient qu’on utilise encore, les binaires du jeu exécutés par le moteur sont indépendant du système d’exploitation (pour faire une analogie, c’est comme avoir un binaire java proprement fait qui est sensé tourner sur la JVM dès lors que la JVM est portée sur une plateforme), donc on compile le code du jeu une fois pour toute sur un système pris en charge (comme Linux), et puis après on compile les binaires du moteur pour Linux, Windows et macOS. Personne n’a jamais tenté de corriger la compilation du « game code » sous macOS, on a reçu des réclamations mais personne pour ne serait-ce qu’identifier ce qui ne marche pas et faire un rapport plus détaillé que « ça ne marche pas ». Il est probable que ce soit lié à l’abandon du 32-bit par macOS car si on produit des binaires indépendant du système d’exploitation, pour le moment on produit toujours une spécialisation i686/amd64 (ça devrait être corrigé avec WebAssembly, on est en train de migrer de NaCl vers Wasm).
Porter des logiciels sous macOS est très ingrat sur plein d’aspects, déjà les utilisateurs qui se manifestent sont vraiment, vraiment, vraiment rares, de deux, ils ne contribuent pas du portage, de trois, ils n’utilisent peut-être même pas de mac fabriqué par Apple ! C’est à se demander pourquoi faire tant d’efforts.
Je me souviens quand il était difficile de trouver des contributeurs Windows, je me souvient que GIMP souffrait beaucoup avec Windows d’une situation similaire à ce que GIMP souffre aujourd’hui avec macOS. Je me souviens aussi quand Darktable ne fournissait pas de binaires Windows, quand j’ai lu la première annoncé de WSL (Windows Subsystem for Linux) j’ai tout de suite pensé que ce serait une excellente manière de faire tourner Darktable sous Windows, mais en fait Darktable est arrivé en natif sous Windows presque en même temps que WSL.
Mais pour Windows, non seulement on semble désormais trouver plus (+) de développeurs, mais
llvmpipe) rend très aisée le test de composants graphiques OpenGL avec une prise en charge complète même sans pass-through.Pour macOS:
Un utilisateur de logiciel gratuit qui demande un portage pour macOS réclame que le développeur achète un mac et travaille sur mac comme environnement de développement, comme ça, gratos, rien de moins.
Pour un éditeur de logiciel payant, ceci peut n’être considéré que comme des achats de fournitures particulières, peut-être moins chères que certains logiciels, mais pour un contributeur bénévole de logiciel gratuit, le coût de développement pour macOS est énorme.
Donc bref, bravo à GIMP et Jehan d’être si généreux 👍, je ne doute pas que de tels efforts sont remerciés par beaucoup d’ingratitude, à commencer par « même pas un merci ». 😏
Message spécial à Jehan : l’intégration des « Pipelines » Microsoft Azure est plutôt efficace avec GitHub et prend désormais en charge macOS (exemple) donc tu peux éventuellement envisager de « profiter du système » en poussant un clone du dépôt GIMP de git sur GitHub et de pousser ta branche de développement macOS sur github pour valider la compilation gratuitement à chaque push de commit. Après tu reviendras à ta solution actuelle pour produire le binaire distribuable. Alors GitHub, Azure, tout ça oui c’est pas très « logiciel libre » mais bon il s’agit de produire un binaire macOS à la base... C’est déjà très très très sale. 😜
ce commentaire est sous licence cc by 4 et précédentes