Microsoft déploie en urgence un correctif pour Windows 11, le deuxième en quinze jours, après qu’une mise à jour de sécurité a semé la zizanie. Les utilisateurs des versions 22H2 et 23H2, particulièrement en environnements virtualisés, peuvent enfin souffler face à une erreur bloquante.
https://clubic.com//actualite-567492-windows-11-deuxieme-patch-d-urgence-en-deux-semaines.html
Les mois se ressemblent, et cela devient de plus en plus catastrophique comme situation. Mais qu’est-ce qu’ils foutent chez Microsoft pour devenir si mauvais depuis 3/4 ans ? Ils veulent aller trop vite, et ne testent plus autant que par le passé. Alors que la stabilité doit primer sur des correctifs déployés trop rapidement.
Quand on paye des centaines de milliers d’€ de licences Windows annuel, c’est inacceptable et honteux de tels problèmes. Si on paye pas pour des mises à jour de sécurité publiées au bon moment, on paye pour quoi ? Certainement pas pour le peu de fonctionnalité que Microsoft daigne donner aux entreprises. Même WSUS qui était certes très rustique et pas du tout ergonomique, vient d’être abandonné …
Une crise de compétences, la suppression progressive du pôle Assurance qualité depuis 2015 et Windows qui veut tout faire tout en priorisant l’intégration de Copilot sur tous les services, au-dessus d’une base bancale.
Pour ça, il vaut mieux passer par WinGet.
Alors que personne, mais alors vraiment personne n’a demandé ni Copilot ni son intégration dans Windows. Même des utilisateurs lambdas sont plus gênés qu’autre chose au quotidien de l’avoir d’intégré (sans compter la confidentialité). Il a des sujets bien plus urgents et prioritaire que ça à faire sur Windows pourtant …
Quand je vois qu’en 10 ans je donne pas loin de 50% de plus à Microsoft, ces réductions de coûts passent encore plus mal.
Winget… est-ce une version windows de AptGet de Linux ?
EN GROS.
C’est censé être un gestionnaire de paquets.
Microsoft l’a pondu en 2020, après tout le monde comme d’habitude.
MacOS a brew depuis 2009 :
https://fr.wikipedia.org/wiki/Homebrew_(gestionnaire_de_paquets)#:~:text=Homebrew a été écrit par Max Howell en 2009
Sous GNU-Linux, ça fait des décennies qu’on installe un paquet avec une seule commande propre, fiable, sécurisée :
apt install firefox ou dnf install firefox.
Résolution des dépendances, mises à jour du système, gestion des versions, tout est prévu.
Sur Windows ? Winget se contente de télécharger un .exe depuis un dépôt communautaire (souvent GitHub) et le lance comme si tu faisais « Suivant > Suivant > Terminer ».
S’il y a une dépendance manquante ? Tant pis pour toi…
Pas de gestion système.
Pas de sécurité avancée (genre signature GPG).
Pas de rétrocompatibilité.
Pas de sandbox.
Pas de gestion propre des configurations.
Mises à jours via winget upgrade --all parfois foireuse.
Même pas de mise à jour de Windows lui-même.
Juste un script glorifié pour cliquer à ta place 
Et évidemment, ça arrive avec 20 ans de retard. Pendant que les distributions GNU/Linux gèrent des milliers de paquets avec fiabilité, winget galère encore à faire la différence entre « installer Discord » et « ouvrir le site web de l’éditeur ».
En fait, winget, c’est juste Microsoft qui découvre apt en 2020, le copie à moitié, et l’emballe dans une couche PowerShell pour faire croire à un miracle.
On dirait qu’ils ont inventé l’eau tiède, sauf qu’elle est tiède depuis 1995 ailleurs.
Si tu veux un vrai gestionnaire de paquets, prends MacOS ou Ubuntu (que tu utilises déja, non?), ou une autre distrib gnunux.
Mais bon, c’est mieux que rien.
Comme ça, tu peux automatiser l’install d’une batterie de logiciels…
de même, il y a aussi CURL sous windows qui fait l’envoie/réception de paquet et données streamées non ? ça suffit pas pour faire des install propres?
Winget est + pratique, même si nettement plus limité que vrai gestionnaire de paquets comme brew, pacman ou dnf.
Avec Winget tu peux faire winget install firefox et il t’installe FF automatiquement, sans que tu aies a trouver l’url de téléchargement.
Si il y a plusieur versions de firrefox dans l’annuaire de Winget, il te retournera les correspondances (Firefox, Firefox ESR, Firefox Nightly, Firefox Dev Edition…), et il te suffira de mettre le nom exacte.
De plus, curl est juste un téléchargeur. Ça ne fait pas l’installation. Ça ne fait que de la réception de données, et bien. La philo Linux, quoi.
Ça existe !?
En même temps ce qui fait la force de Windows ces 30 dernières années, c’est la liberté à pouvoir installer n’importe quoi, n’importe comment et ne pas être lié à un package manager. La notion de gestion de paquets par CLI est une notion récente, juste pour faire comme les 2 autres grands OS. C’est pour satisfaire une niche d’utilisateurs : les utilisateurs avancés et développeurs
- Pas de sécurité avancée (genre signature GPG).
Certains installateurs vérifient la signature, mais ce n’est pas la norme.
La rétrocompatibilité est justement le point fort de Win32, mais ce dernier ne tourne pas dans le sandbox intégré de Windows qui est réservé aux applications modernes…
Là aussi pour des raisons historiques les configurations se trouvent partout : Appdata/roaming, Appdata/local ou même le dossier de l’application.
Pour la question des dépendances, le développeur l’inclut généralement dans son installateur, heureusement.
Si tu crédites MacOS pour Brew, qui est fait par un tiers, alors tu peux créditer Windows pour Steam ou Chocolatey, qui sont fait par des tiers aussi… 2011 pour Chocolatey, 2003 pour Steam.
Winget est arrivé en 2020, avec un énième « machin-preview-MSStore-en-mode-suggestion », pendant que sur Linux on gérait déjà des dizaines de milliers de paquets signés, versionnés, testés, et rollbackables depuis 20 ans. Même macOS avait déjà Brew depuis 2009.
Et encore, Brew c’est communautaire.
Winget, c’est Microsoft eux-mêmes qui l’ont sorti… en 2020. Deux mille vingt.
Quand tout le monde avait déjà apt, dnf, zypper, pacman, pkg, et même flatpak, snap, etc.
Justement. Certains. Quand ils veulent.
Y’a pas de politique globale.
Sur dnf, tout est signé GPG. Sinon, ça gueule.
Sur winget, si l’éditeur du .exe fout n’importe quoi dans son script d’install, tant pis pour toi 
. C’est comme ça que ls répertoire systeme et le registre s’encradent, surtout si tu installe-désinstalle bcp de softs.
Et il peut installer du crapware dans ton %AppData% ou modifier le registre, sans demander ton avis. 
Bon, ça arrive aussi avec Linux, les problèmes de deps, je le reconnais.
Bref…
Quand tu parles de Steam, il s’agit de la boutique de jeux ?
En revanche je ne conais pas Chocolatey Matt. C’est bien 
?
J’ai une machine avec Atlas OS (pour jouer, et surtout faire de la bidouille). Pour l’instant je suis sur winget, même si c’est mieux que rien, c’est pas foufou…
Non, macOS n’avait pas. Des tiers l’y ont ajouté.
Oui, et ? Y a rien de choquant à ce qu’une communauté fasse mieux qu’un gros éditeur sur certains points : une communauté fait en fonction de ses besoins, un éditeur fait avec des objectifs de rentabilité… Donc une communauté motivée par une fonctionnalité peut mettre bien plus de moyens qu’un éditeur qui ne la juge pas forcément cruciale.
Surtout qu’en plus les contraintes ne sont pas non plus les mêmes. Si un brew install te casse ton environnement, la communauté n’est pas responsable… Si par contre un winget install te fout en l’air ton Windows, c’est sur Microsoft que ça va retomber…
Accessoirement, Microsoft n’a certes fait winget qu’en 2020, mais sinon ils ont quand même déjà aussi fait un gestionnaire d’applications depuis 2012… Avec un format spécifique pour garantir une uniformité, comme les gestionnaires de paquets Linux.
Et au passage, ce que tu vois comme un défaut de winget et aussi un avantage, le fait de se reposer sur des installeurs existants, ça permet de l’utiliser pour installer et gérer des logiciels sans que leur éditeur n’ait nécessairement fait l’effort de le repackager pour Winget…
Sous Linux, si tu installes un truc qui n’est pas packagé en rpm ou deb, tu n’auras strictement rien pour gérer… Tu n’as même pas de système pour simplement référencer ce qui est installé autrement qu’avec le gestionnaire de paquets…
Et forcément dans le monde Linux c’est plus facile de faire un gestionnaire de paquets qui nécessite un repackaging, parce que pour les distributions ils recompilent tout à partir des sources, chose inenvisageable pour Microsoft dans le monde Windows, où il y a beaucoup de logiciels propriétaires.
C’est plus complet que winget, et plus proche des principaux gestionnaires de paquets Linux, mais par contre ça nécessite de repackager les applications, donc faut un effort de l’éditeur.
Oui. Techniquement, c’est bien un outil qui gère les installations/désinstallations/mises à jour d’applications.
Alors sur Linux, t’as pas « rien » en dehors de .rpm ou .deb, t’as :
rpm, deb, zst, etc.)make install si t’es old school (et checkinstall pour désinstaller)Bref, y’a plein de façons d’installer sous Linux. Et à la différence de Windows, même quand c’est à la main, c’est souvent plus propre et traçable.
Alors voui, ya plusieurs formats pour Gnunux…
mais chacun a un usage clair (Flatpak pour GUI, AppImage pour portable, etc.).
Et surtout : ils peuvent coexister proprement.
Sur Windows, t’as 3 launcheurs (menuu démarer, raccourcis dans le dossier, raccourci sur le bureau, en fonction de 'humeur du dev. Bon, heureusement la plupart on l’humanité de proposer des options pour ça dans l’installateur.), 5 installateurs, rien de centralisé ( L’équivalent du dpkg ou rpmdb sur Linux… n’existe pas vraiment.), et aucun format standardisé.
Le Microsoft Store est un échec, peu de gens passent par là (je n’en suis pas sur, maiis ça ne m’étonnerait pas).
MS Store + .msi ?
Ah, oui. Je suis anti-windows et Gafa en général, alors si vous me trouvez de mauvaise foi, que je pousse le boucon trop loin, etc… signalez le (à moi, pas au modo!)
Sur une distribution Linux on peut aussi installer des programmes qui ne sont pas dans les dépôts (et d’ailleurs, on peut aussi ajouter des dépôts - même si en termes de sécurités, ça peut ne pas être fou).
Alors, certes parfois, sous Linux / xBSD, il faut compiler le programme pour l’installer et là, ça peut vite devenir complexe (et la gestion des dépendances à la mano, hmmm 
). 
Certes, mais ça peut vite faire un sacré bazar dans lequel il peut être compliqué pour trouver ce que l’on cherche.
Edit : Comme j’ai déjà pu le dire, GNU / Linux, xBSD et Windows sont différents dans leur architecture et tous ont un héritage avec de bonnes et de moins bonnes choses (genre /etc/rc. conf de FreeBSD, c’est un fichier texte, donc très facile pour gérer ce qu’il charge au démarrage, mais ce fichier peut vite devenir un beau capharnaüm 
).
C’était une façon de parler, j’allais pas lister tous les formats de paquets (ce qui, au passage est un problème pour le grand public…). L’idée c’était de dire que quand c’est pas packagé dans un format de paquet, tu te retrouves avec un truc qui va aller poser ses fichiers là où il veut, sans moyen standard de s’enregistrer auprès du système pour que ça apparaisse quelque part dans une liste d’applications installées pour pouvoir gérer ça. Sous Windows, même si tu fais ton propre installeur custom, tu peux aller déclarer ton application pour qu’elle apparaisse dans la liste des applications installées, avec un bouton pour la désinstaller…
Je ne compte plus le nombre de fois ou pour installer un outil sous Linux la méthode préconisée c’est de faire un curl <url du script d’install> | bash ou pire, la même chose avec un sudo devant le bash…
Ce qui non seulement est crade et très peu traçable, mais en plus est très moyen pour la sécurité, directement, mais aussi indirectement (parce que y a une multitude de truc qui aujourd’hui sont buildés avec une CI qui utilise ce genre de commande pour installer les outils nécessaires pour le build…).
Et je parle même pas de la joie des paquets qui changent de nom d’une distro à l’autre, avec parfois du coup pas du tout ce que tu attendait (coucou le paquet docker de Ubuntu 
), des fonctionnalités qui varient très fortement en fonction du type de packaging (encore une fois, coucou docker sous Ubuntu : la version snap qui est préconisée par Canonical et qui est celle qui s’installe quand tu coches la case « docker » à l’install d’un serveur Ubuntu est juste une catastrophe…), ou encore des commandes qui changent de nom d’une distrib à l’autre (coucou bat qui s’appelle batcat sous Ubuntu… mais qui s’installe quand même avec apt install bat parce que… ben parce que quoi…).
Et bonus, tu te retrouves même avec des cas où pour installer un outil dans sa dernière version, la seule solution « propre » (ie reproductible, automatisable, et sans avoir à aller bidouiller manuellement des fichiers) c’est de l’installer trois fois dans deux versions différentes (coucou Ubuntu LTS et son pipx antédiluvien, qui fait que si on veut profiter d’un pipx récent et disponible pour tous les utilisateurs il faut installer le pipx fourni par Canonical, utiliser ce pipx pour installer chez root un pipx récent, et enfin utiliser ce second pipx pour installer pour tous un autre pipx).
Et d’ailleurs de manière générale, quand tu veux la dernière version d’un logiciel, c’est rarement avec les dépôts standards de la distribution que tu vas les avoir… C’est un atout dans certains cas, mais c’est aussi super emmerdant dans d’autres cas, et notamment quand la distrib a packagé à sa façon et que la conf que tu as faite pour la version qui vient avec la distro n’est pas compatible avec une version plus récente installée différemment, t’obligeant à reprendre manuellement tes configs…
Bref, contrairement à ce que tu sembles croire, il n’existe pas de système d’exploitation qui gère de façon totalement satisfaisante les applications, et les systèmes de boutiques applicatives qu’on trouve sur les principaux OS grand public, même s’ils sont eux aussi très loin d’être parfaits, sont largement plus adaptés à l’utilisateur lambda que les gestionnaires de paquets classiques.
Abandonné depuis dix ans, et déconseillé depuis longtemps…
Tellement clair que non, c’est pas ça. La caractéristique fondamentale du Flatpak, c’est pas de gérer des applications GUI (ça se gère tout a fait aussi avec du deb, du RPM, du snap, de l’install à la mano…), c’est le sandboxing.
@MattS32 Ce que tu racontes me fait penser au cirque international qu’a été l’installation d’un programme en Python pour gérer mon Stream Deck XL sur Mint LMDE 6 (la version actuelle) il y a quelques mois.
Première manche : J’ai évidemment installé la version (et ses dépendances) des dépôts de la version stable.
Ca s’est installé sans effort, le programme démarre, mais … le Stream Deck n’est pas reconnu parce que c’est une nouvelle révision.
Evidemment. 
Deuxième manche : Quelques recherches, okay, la seule version qui fonctionnerait est récupérable avec pip …
Problème, il est désactivé par défaut sur Debian, justement parce que les packages python sont gérés par apt (et les dépôts).
Bref, je désactive, je lance ensuite pip pour insaller le soft dont j’ai besoin et … Le nombre de dépendance qu’il a téléchargées et installées. What the Fluff !? 
Install faite, je lance le soft, il démarre, le Stream Deck est bien reconnu …
Première action que je test, paf terminé bonsoir, le soft se ferme sans crier gare (et aucun log) …
Reboot, je vire les fichiers de configs, je redémarre le soft, toujours pareil.
… Bon, c’est pas gagné.
Pas le choix, je plonge dans les fichiers .py (j’adore, y a pas … ), coup de bol, j’arrive à repérer le fonctionnement du bazar pour la reconnaissance du matériel.
J’ai copié les fichiers de cette version dans un coin.
Troisième manche, le boss final : J’ai viré tout le cirque installé (une partie de plaisir ).
J’ai réactivé le support de Python via les dépôts et apt.
Réinstallé la version des dépôts du soft dont j’avais besoin et bricolé les fichiers de supports du matériel pour y ajouter la révision de mon Stream Deck XL. 
Par contre, après cette bataille, cela fonctionne ! 
Alors, oui, ça a été épique et évidemment pas à la portée de tout le monde, mais au moins, le fait que le soft soit open source m’a permis de bricoler pour arriver à mes fins (mais quel enfer 
).
Et tout ça parce que la dernière version du logiciel n’est pas dans les dépôts.
Cependant, attention, ce n’est pas de ma part une critique de Debian, je connais cet état de fait (que les versions livrées ne sont pas les dernières et qu’elles ne seront pas mises à jour, sauf exceptions types Firefox, vers une version majeure pendant la vie de la version en cours de la distrib).
Par contre, en effet, dans ce genre de cas, c’est très loin d’être accessible.
En ce qui me concerne, mine de rien, j’étais content, parce que cela fonctionne et en plus, j’ai appris des trucs (mais je conçois que lorsque l’on est utilisateur, on n’a pas forcément le temps pour bricoler à ce point).
Pour info, le pipx dont je parle c’est justement pour règler ce problème.
Historiquement, le Python installé avec le système était open bar, et du coup y avait vite moyen de foutre une grouille pas possible (toutes les dépendances de tous les softs Python installées dans le même environnement…) et des blocages inextricable (A dépend de D version 2 maximum, B dépend de D version 3 minimum, comment je fais pour installer à la fois A et B ?).
Et le bordel quand tu développes, puisque tu peux te retrouver avec ton soft qui a des dépendances que tu n’avais pas remarquées, parce que c’était déjà installé et que du coup t’as pas remarqué qu’il fallait l’installer pour faire tourner ton soft…
Donc très vite il y a eu les venv, pour pouvoir faire un environnement pour chaque soft, mais c’est chiant, faut penser à le faire, faut activer le venv à chaque fois que tu veux utiliser le soft, etc…
Et c’est là qu’arrive pipx : tu l’installes avec apt (ou autre gestionnaire, il est dans les dépôts de plusieurs dizaines de distros), et ensuite au lieu d’installer tes applis Python avec pip install tu les installes avec pipx install. Ça te gère automatiquement la création du venv, éventuellement avec une version de Python différente de celle du système (par exemple si tu dois faire tourner un truc qui veut un Python 3.11 alors que celui livré avec ton système est le 3.12), à condition qu’elle soit déjà installée (et si pas dans le PATH, faut lui dire où elle est), et ça te crée un petit script qui va te permettre de lancer ton appli directement, sans avoir à activer manuellement le venv avant. Et c’est ce script qui va être mis dans le path, avec le même nom que la commande d’origine, donc c’est totalement transparent.
Et du coup t’es certain de pas pourrir ton système en plombant l’environnement Python standard, et t’as aucun problème de conflit de dépendances.
Tu peux même installer plusieurs fois le même paquet Python, avec le suffixe de ton choix, comme ça par exemple si tu as installé Poetry v1 et que tu veux tester Poetry v2 avant de l’adopter, tu peux faire pipx install poetry --suffix _2, et tu pourras utiliser Poetry v2 avec la commande poetry_2, pendant que la commande poetry tout court continuera à lancer la v1. Puis une fois satisfait, tu fais un pipx upgrade poetry, puis un pipx uninstall poetry_2, et ta commande poetry tout court sera désormais la v2.