Il est encore plus simple aujourd’hui de travailler et de mettre en pratique des méthodes de travail sous Windows comme si c’était Linux grâce à WSL2, oui.
Mais je ne crois pas que WSL2 aide à produire des binaires natifs Windows, puisque le principe de WSL c’est de faire tourner des binaires Linux. À la rigueur ça donne accès aux outils de cross-compilation, mais autant utiliser MSYS2/MingW directement.
Cela dit ton commentaire répond en partie à des points évoqués dans le fil de discussion partagé par Gil, où il se dit des choses comme « Au moins un mac de base reste un Unix qui te fournit un shell, python, perl, awk, les commandes de base (attention, syntaxe BSD), les clients ssh, etc. »
Eh bien sur ce plan, Windows n’est plus vraiment en reste. Ça fait peut-être 10 ans que j’utilise des trucs comme Cygwin, et avec MSYS2 qui propose un gestionnaire de paquet utilisable comme sous linux (pacman de Arch Linux), c’est devenu vraiment très pratique. J’ai pu me servir de CoLinux il y a 15 ans, mais c’était trop séparé du système (même expérience que si on utilise une machine virtuelle), et avec Cygwin puis MSYS2, c’est devenu incroyablement pratique. J’ai eu des expériences très satisfaisantes avec Cygwin combiné avec un serveur X sous Windows (historiquement Xming, puis VcXsrv.
Microsoft améliore très sérieusement la prise en charge de certaines méthodes de travail directement héritées de Linux, on est très loin des « Services For Unix » que je n’ai jamais vraiment pu exploiter correctement.
WSL2 cela s’inscrit dans une dynamique où Microsoft ne veut pas voir son système de poste de travail utilisateur et de serveur être exclu de fait parce que Linux a gagné, que le monde tourne sur Unix/Linux et applique les méthodes de travail d’Unix/Linux. Personne n’est vraiment intéressé par un docker qui fournit un environnement NT avec un shell cmd.exe ou Powershell au lieu de Linux et Bash, et les gens et les entreprises veulent docker, et quand ils pensent docker, ils pensent Linux, les coreutils, etc. Microsoft a changé sa politique sur la création des liens symboliques après avoir migré sur Git comme le reste de l’industrie (avant seul l’administrateur avait ou pouvait avoir le droit d’en créer). Microsoft a même cédé sur le codage des fins de lignes des fichiers textes (même Notepad sait désormais correctement traiter les \n seuls comme des fins de ligne), ce qui permet désormais de convertir tous ses fichiers sources au format Unix sans mettre en place des conversions au checkout/commit.
D’une certaine manière, avec sa syntaxe BSD, l’environnement du shell de macOS est plus éloigné de GNU/Linux (là ça fait particulièrement sens de citer GNU/Linux) que Windows avec Cygwin, MSYS2 ou WSL. Je disais que j’utilisais les mêmes scripts pour Linux, Windows, FreeBSD et macOS pour compiler NetRadiant, mais en fait ces scripts font deux spécialisations, une pour Linux et Windows, une autre pour FreeBSD et macOS. Dans le cas de NetRadiant la difficulté suivante étant que l’environnement de bureau (technologie d’affichage) est très différent sous macOS et moins bien pris en charge par GTK, ce qui fait que là où FreeBSD et macOS forment un cas particulier par rapport à Linux et Windows, macOS devient un sous-cas particulier de la particularité FreeBSD/macOS.
Le truc dont je rêve désormais pour Windows, c’est un équivalent de rpath pour les chemins relatifs de bibliothèques. J’utilise actuellement la méthode de Microsoft qui est sensée la remplacer mais c’est vraiment pas un équivalent en terme de souplesse et de fonctionnalité. Il me manque peut-être des informations, mais actuellement je suis obligé de lister à l’avance les bibliothèques dont le chemin d’accès n’est pas par défaut, et le chemin de ces bibliothèques embarquées, bien que relatif, a beaucoup de contraintes. Au moins pour macOS, si les outils sont différents, les fonctionnalités sont globalement les mêmes et fonctionnent pareil, du moins pour mes besoins.
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é à 9.
Il est encore plus simple aujourd’hui de travailler et de mettre en pratique des méthodes de travail sous Windows comme si c’était Linux grâce à WSL2, oui.
Mais je ne crois pas que WSL2 aide à produire des binaires natifs Windows, puisque le principe de WSL c’est de faire tourner des binaires Linux. À la rigueur ça donne accès aux outils de cross-compilation, mais autant utiliser MSYS2/MingW directement.
Cela dit ton commentaire répond en partie à des points évoqués dans le fil de discussion partagé par Gil, où il se dit des choses comme « Au moins un mac de base reste un Unix qui te fournit un shell, python, perl, awk, les commandes de base (attention, syntaxe BSD), les clients ssh, etc. »
Eh bien sur ce plan, Windows n’est plus vraiment en reste. Ça fait peut-être 10 ans que j’utilise des trucs comme Cygwin, et avec MSYS2 qui propose un gestionnaire de paquet utilisable comme sous linux (pacman de Arch Linux), c’est devenu vraiment très pratique. J’ai pu me servir de CoLinux il y a 15 ans, mais c’était trop séparé du système (même expérience que si on utilise une machine virtuelle), et avec Cygwin puis MSYS2, c’est devenu incroyablement pratique. J’ai eu des expériences très satisfaisantes avec Cygwin combiné avec un serveur X sous Windows (historiquement Xming, puis VcXsrv.
Microsoft améliore très sérieusement la prise en charge de certaines méthodes de travail directement héritées de Linux, on est très loin des « Services For Unix » que je n’ai jamais vraiment pu exploiter correctement.
WSL2 cela s’inscrit dans une dynamique où Microsoft ne veut pas voir son système de poste de travail utilisateur et de serveur être exclu de fait parce que Linux a gagné, que le monde tourne sur Unix/Linux et applique les méthodes de travail d’Unix/Linux. Personne n’est vraiment intéressé par un docker qui fournit un environnement NT avec un shell cmd.exe ou Powershell au lieu de Linux et Bash, et les gens et les entreprises veulent docker, et quand ils pensent docker, ils pensent Linux, les coreutils, etc. Microsoft a changé sa politique sur la création des liens symboliques après avoir migré sur Git comme le reste de l’industrie (avant seul l’administrateur avait ou pouvait avoir le droit d’en créer). Microsoft a même cédé sur le codage des fins de lignes des fichiers textes (même Notepad sait désormais correctement traiter les
\nseuls comme des fins de ligne), ce qui permet désormais de convertir tous ses fichiers sources au format Unix sans mettre en place des conversions au checkout/commit.D’une certaine manière, avec sa syntaxe BSD, l’environnement du shell de macOS est plus éloigné de GNU/Linux (là ça fait particulièrement sens de citer GNU/Linux) que Windows avec Cygwin, MSYS2 ou WSL. Je disais que j’utilisais les mêmes scripts pour Linux, Windows, FreeBSD et macOS pour compiler NetRadiant, mais en fait ces scripts font deux spécialisations, une pour Linux et Windows, une autre pour FreeBSD et macOS. Dans le cas de NetRadiant la difficulté suivante étant que l’environnement de bureau (technologie d’affichage) est très différent sous macOS et moins bien pris en charge par GTK, ce qui fait que là où FreeBSD et macOS forment un cas particulier par rapport à Linux et Windows, macOS devient un sous-cas particulier de la particularité FreeBSD/macOS.
Le truc dont je rêve désormais pour Windows, c’est un équivalent de
rpathpour les chemins relatifs de bibliothèques. J’utilise actuellement la méthode de Microsoft qui est sensée la remplacer mais c’est vraiment pas un équivalent en terme de souplesse et de fonctionnalité. Il me manque peut-être des informations, mais actuellement je suis obligé de lister à l’avance les bibliothèques dont le chemin d’accès n’est pas par défaut, et le chemin de ces bibliothèques embarquées, bien que relatif, a beaucoup de contraintes. Au moins pour macOS, si les outils sont différents, les fonctionnalités sont globalement les mêmes et fonctionnent pareil, du moins pour mes besoins.ce commentaire est sous licence cc by 4 et précédentes