Après, oui il est toujours possible d'aller sur 50.000 sites différents, mais c'est pareil sous Linux, rien ne m'empêche d'aller chercher les logiciels upstream (bon, dans 90% des cas, ça veut dire que je vais devoir compiler moi même).
Dans les faits avec la mode des installations à base de curl | bash et allez chercher ma dernière release sur github, c'est le cas quelque soit l'OS.
Exemple tout con, les outils pour kubernetes. Bien que le projet soit libre, le fait que kubectl supporte les versions de kubernetes n-1 à n+1 et que le projet kubernetes sort environ 4 nouvelles versions par an rend difficile le suivi pour une distro ayant un cycle de sortie de 6 mois ou plus. Résumé la majorité des distros ne proposent pas les kubectl/kubeadm dans les repos principaux, ou alors dans une version particulière ou via un type de packaging différent (snap chez ubuntu) car il est compliqué de maintenir x versions différentes à la fois. Supposément des distros comme nix résoudraient ce problème mais dans les faits ce n'est pas le cas car les mainteneurs downstream ne suivent pas forcément le rythme.
Du coup dès qu'on gère de la prod on se retrouve généralement à installer les binaires kubectl à la main, des containers ou à utiliser des projets de gestions de version comme asdf pour avoir les versions de kubectl qui convient au cluster utilisé.
Idem pour tous les languages de programmation ou fleurissent les gestionnaires de versions pour maintenir n versions à la fois dans son homedir comme nvm pour le monde javascript, sdk pour le monde apache/java, rvm pour ruby, les gestionnaires d'environnemnets et de versions de python etc etc.
La gestion des paquets et la maintenance downstream fonctionne assez bien pour l'utilisateur final, mais quelque soit l'OS, un developpeur va toujours installer des trucs à la main, utiliser des projets de gestions d'environnements/versions et/ou des containers pour gérer plus finement et de manière plus agile ses environnement des développement. Sous linux il n'y a peut-être que les devs C/C++ qui se contentent de ce qui est fourni par une distro linux.
Ma remarque initiale n'était pas qu'on ne peut pas developper sous windows, mais que si on termine par avoir un kernel linux qui tourne dans des VMs et qu'on finit par n'installer que des outils dispos sous linux, faire tourner ça sous windows n'ajoute qu'un overhead et des complexités inutiles, un environnement de bureau hostile (je n'ai pas testé le 11, mais l'ergonomie, la gestion du clavier et des fenêtres sous windows jusqu'à 10 est proprement horrible), une gestion des fin de lignes/retour chariot différent selon les outils utilisé, des possibles pertes de performances dues aux outils déployés par les IT Exemple tout bête le windows 10 fournit par ma boite contient un outil vpn cisco qui fait sauter toutes les connections de WSL, des VMs et impose de passer une commande powershell en admin à chaque occurence pour changer la priorité des interfaces et retrouver le réseau sur celles-ci...ce qui arrive à minima à chaque fois que je déconnecte/connecte le laptop au dock usb-c si j'ai un câble ethernet branché à celui-ci. Du coup de plus en plus de gens, dont je fais partie n'utilisent plus le windows et bootent directement sous linux car à quoi bon garder la couche windows si elle ne sert que comme socle d'hyperviseur pour un environnement linux?
[^] # Re: Euh, oui, mais non
Posté par Psychofox (Mastodon) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 4. Dernière modification le 30 décembre 2022 à 11:47.
Dans les faits avec la mode des installations à base de curl | bash et allez chercher ma dernière release sur github, c'est le cas quelque soit l'OS.
Exemple tout con, les outils pour kubernetes. Bien que le projet soit libre, le fait que kubectl supporte les versions de kubernetes n-1 à n+1 et que le projet kubernetes sort environ 4 nouvelles versions par an rend difficile le suivi pour une distro ayant un cycle de sortie de 6 mois ou plus. Résumé la majorité des distros ne proposent pas les kubectl/kubeadm dans les repos principaux, ou alors dans une version particulière ou via un type de packaging différent (snap chez ubuntu) car il est compliqué de maintenir x versions différentes à la fois. Supposément des distros comme nix résoudraient ce problème mais dans les faits ce n'est pas le cas car les mainteneurs downstream ne suivent pas forcément le rythme.
Du coup dès qu'on gère de la prod on se retrouve généralement à installer les binaires kubectl à la main, des containers ou à utiliser des projets de gestions de version comme asdf pour avoir les versions de kubectl qui convient au cluster utilisé.
Idem pour tous les languages de programmation ou fleurissent les gestionnaires de versions pour maintenir n versions à la fois dans son homedir comme nvm pour le monde javascript, sdk pour le monde apache/java, rvm pour ruby, les gestionnaires d'environnemnets et de versions de python etc etc.
La gestion des paquets et la maintenance downstream fonctionne assez bien pour l'utilisateur final, mais quelque soit l'OS, un developpeur va toujours installer des trucs à la main, utiliser des projets de gestions d'environnements/versions et/ou des containers pour gérer plus finement et de manière plus agile ses environnement des développement. Sous linux il n'y a peut-être que les devs C/C++ qui se contentent de ce qui est fourni par une distro linux.
Ma remarque initiale n'était pas qu'on ne peut pas developper sous windows, mais que si on termine par avoir un kernel linux qui tourne dans des VMs et qu'on finit par n'installer que des outils dispos sous linux, faire tourner ça sous windows n'ajoute qu'un overhead et des complexités inutiles, un environnement de bureau hostile (je n'ai pas testé le 11, mais l'ergonomie, la gestion du clavier et des fenêtres sous windows jusqu'à 10 est proprement horrible), une gestion des fin de lignes/retour chariot différent selon les outils utilisé, des possibles pertes de performances dues aux outils déployés par les IT Exemple tout bête le windows 10 fournit par ma boite contient un outil vpn cisco qui fait sauter toutes les connections de WSL, des VMs et impose de passer une commande powershell en admin à chaque occurence pour changer la priorité des interfaces et retrouver le réseau sur celles-ci...ce qui arrive à minima à chaque fois que je déconnecte/connecte le laptop au dock usb-c si j'ai un câble ethernet branché à celui-ci. Du coup de plus en plus de gens, dont je fais partie n'utilisent plus le windows et bootent directement sous linux car à quoi bon garder la couche windows si elle ne sert que comme socle d'hyperviseur pour un environnement linux?