Le Wi-Fi 7, ou plus précisément le IEEE 802.11be Extremely High Throughput (EHT), n’est actuellement pas pris en charge par défaut par Windows 11. On peut s’en étonner, alors que la norme est finalisée et que des produits sont déjà disponibles depuis longtemps.
Ce support a été ajouté dans la dernière build du canal Canary de Windows 11. La société en profite pour rappeler les multiples avantages de cette nouvelle norme, dont la vitesse, la faible latence ou encore la gestion de la connexion. Elle rappelle – bien sûr – qu’il faut un matériel adapté.
La présence dans le canal Canary signifie qu’il faudra probablement plusieurs mois avant que cette gestion du Wi-Fi 7 par défaut arrive jusque dans les chaumières. Il est dans tous les cas déjà possible de profiter du Wi-Fi 7 dans Windows 11. il faut simplement installer les pilotes adéquats. Intel par exemple en propose pour Windows 7. 8. 10 et 11 pour sa puce BE200 (Wi-Fi 7).
Autre apport en approche, le hot patching. Derrière ce nom se cache une technique permettant d’installer une mise à jour sans que le système ait à redémarrer. Ce mécanisme n’a rien de neuf et on le trouve dans divers systèmes. Canonical le propose par exemple depuis des années aux entreprises sur Ubuntu. Il est également présent dans l’édition Server de Windows.
Windows Central a repéré que le mécanisme allait être importé dans le client Windows. Microsoft a ajouté les premiers éléments dans la dernière build du canal Dev et mis en ligne une page dédiée au mécanisme.
L’ajout devrait se faire dans la mise à jour 24H2 de Windows 11, prévue pour le second semestre. Seule la mouture x86 serait concernée dans un premier temps, la version ARM64 n’arriverait qu’en 2025. Notez que Microsoft doit encore confirmer qu’il s’agit bien de son intention. On ne sait pas non plus si cet ajout serait pour tout le monde ou dédié aux entreprises.
Commentaires (28)
#1
#1.1
#1.2
#1.3
Il y a toujours la possibilité depuis 2012 d'installer une Windows Server Core pour limiter le nombre de mises à jours (pas de Gui, plusieurs composants/rôles non installés par défaut)
#1.4
https://redmondmag.com/articles/2023/12/01/windows-server-vnext.aspx
#1.5
#1.6
#1.7
Nous avons d’ailleurs partiellement l’antériorité avec la marque Next Inpact.
Viens te battre Satya si tu l’oses 🤜🤛
#1.8
Vu qu'ils utilisent ce nom pour leurs serveurs, ça m'étonnerait qu'il l'aient déposé aussi pour la presse.
#1.9
Analyse faite par des avocats en PI dans notre cas, j’ai estimé que ça se tentait. L’avenir nous dira si j’ai misé juste.
Les jeux sont faits, rien ne va plus.
#1.10
Je me disais aussi...
#2
Ce n'est pas spécifique à Ubuntu, ça a toujours été natif sous linux. À part l'upgrade (changement de noyau) tout se fait en live avoir besoin de rebooter.
Depuis 2015 (v4.0) le noyau gère le live patching et peut se màj sans reboot, mais je ne sais pas si c'est implémenté dans une distribution
#2.1
Pour le live patching, c'est implémenté par redhat dans des noyaux entreprise.
Microsoft implémente ici un peu la même chose: ils patchent les exécutables en live. Mais attention: seulement 2 mises à jour sur trois seront compatibles d'après leur graphe, car pour que ça fonctionne il faut rester sur la même "baseline"
#2.2
Le paquet needrestart s'occupe de redémarrer les process qui en ont besoin après un upgrade.
Pour les changements de Kernel il faut reboot sur presque toutes les distrib.
Il me semble que Canonical propose les MAJ kernel sans reboot sur les licences entreprises.
#2.3
Pour une librairie, la nouvelle est installée, l'ancienne est marquée "à supprimer" les applis encours finissent avec l'ancienne version, les nouvelles applis tournent avec la nouvelle, dès que plus rien n'utilise l'ancienne lib, elle est physiquement supprimée.
Le redémarrage totale n'est pas nécessaire, après j'imagine que c'est plus une habitude pour éviter de regarder la liste des màj et être sûr de ne pas oublier de redémarrer des services. Avec la virtualisation je suppose qu'on a plutôt une VM par service et du coup autant rebooter toute la VM qu'un service.
#2.4
Fedora explique pourquoi ils demandent désormais systématiquement un reboot : Restarting and Offline Updates.
Notons que cela ne concerne pas les applications sous forme de Flatpak, dont les nouvelles versions s'installent en parallèle de celles en cours d'utilisation et ne sont mises à jour qu'au moment de relancer l'application. Elles ne peuvent donc pas causer le moindre souci.
#2.5
#2.6
Je n'ai pas Fedora, mais je n'ai jamais observé ça sur ma distrib (qui utilise pourtant systemd).
"Finally, you can hard brick your system. If the system that crashes happens to be DNF or systemd, then it might not be possible for the system to continue its update process. When this happens, even restarting the machine will not be enough to restore it."
Ah ok, je dois être plus chanceux que la moyenne (mais ça m'étonnerait).
"Many of you have never experienced a system bricking, but on the whole those stories are very common on social media."
C'est marrant je vois plus souvent dire que Linux est stable.
Mais que vois-je, tout ça sert au final à faire la promotion de Flatpak.
Historique des modifications :
Posté le 27/02/2024 à 13h37
"If that’s the case, then systemd won’t go into a full system start-up, but will instead start the package manager and apply the updates. Once the updates are completed systemd will then restart the machine a final time. "
Je n'ai pas Fedora, mais je n'ai jamais observé ça sur ma distrib (qui utilise pourtant systemd).
"Finally, you can hard brick your system. If the system that crashes happens to be DNF or systemd, then it might not be possible for the system to continue its update process. When this happens, even restarting the machine will not be enough to restore it."
Ah ok, je dois être plus chanceux que la moyenne (mais ça m'étonnerait).
#2.7
L'étape suivante étant les distributions immuables telles que Fedora Atomic Desktops (Silverblue, Kinoite…) qui séparent le système des applications utilisateur. Les paquets ne sont plus mis à jour un à un comme sur les distributions traditionnelles, mais tu récupères une nouvelle image de base, la même pour tout le monde, mise à jour quotidiennement.
La mise à jour ne s'effectuant qu'en cas de réussite, qu'il y ait une coupure de courant en plein milieu de la procédure ou n'importe quel autre problème, ça n'a aucune importance. De plus, contrairement aux distributions traditionnelles qui ne permettent que de revenir sur un précédent noyau, alors qu'un problème peut très bien concerner d'autres composants, là tu peux facilement revenir sur la précédente image fonctionnelle, voir celle des 90 derniers jours pour certaines distributions. Tout comme tu peux facilement tester la version beta de la prochaine version, pour finalement revenir à la version stable si ça te chante.
Et pour le coup oui, toutes les applications graphiques sont au format Flatpak 😁
#2.8
Mais mes expériences Linux, si elles ont de bons côtés, en ont aussi de mauvais. Exemple: double (triple?) Passage de mise à jour sur un proxmox sans redémarrer - au redémarrage suivant, tout était cassé.
Motif? Aucune idée... Mais impossible de se loguer même en console. Il acceptait le login et revenait à la demande de login immédiatement. Bref, ça arrive.
Pour le redémarrage: si on ne redémarre pas, il faut être un savré spécialsite pour dire que tout ce qui tourne est à jour. Donc le message est: redémarrez.
Sous windows, c'est pareil: cça m'arrive de ne pas redémarrer l'ordi, juste les services concernés - mais je connais très bien mon windows, donc je me le permets :)
Et oui, il y a parfois de mauvaises surprises vec les mises à jour. Mais même quand je gérais une bonne centaine de VM et de serveurs physiques et indirectement des centaines de postes, c'est arrivé très rarement (windows 2003 et 2008 m'ont donné du fil à retordre parfois -mais c'était surtout un ordonnancement des services qui posait problème, jamais de poste utilisateur totalement hs)
#2.9
À côté de ça, il peut également y avoir tout plein de régressions plus ou moins emmerdantes. Même si le système démarre sans problème, si l'impression est cassée, que le bluetooth déconne ou tout autre souci, on peut rapidement revenir à la dernière version qu'on sait fonctionnelle, sans avoir besoin de bidouiller quoi que ce soit, le temps que le problème soit corrigé upstream.
#2.10
C'est faux, si le fichier est en cours d'utilisation, il reste disponible dans l'ancienne version : C'est le principe de base des inodes. Le cas foireux c'est une appli ouverte qui a utilisé une lib, l'a libéré de sa mémoire (faute d'usage), puis la réutilise après qu'elle ait été mise à jour : si l'appli est codé avec les pieds, que l'API de la lib a été modifié, le programme ouvert pourrait planter. (il suffit alors de le fermer / rouvrir)
Par contre, le soft (qui est resté ouvert pendant la màj) a dû être identifié comme à mettre à jour par le gestionnaire de paquets... donc tu étais a priori au courant du risque. :)
Oui c'est exactement le principe d'une mise à jour...
Fedora, dans le même article, explique que les mises à jour sans reboot marchent bien cf § "Doing live updates"
Après comme je le disais dans mon premier message, il faut regarder la liste de paquets à màj avant de valider. Si dans la liste, il y'a ton gestionnaire de fenêtre ou konsole, et que tu lances la mise à jour depuis konsole, il y'a un léger risque que konsole plante pendant la mise à jour et interrompe le process au milieu, voire laisse ton système sans interface graphique.
Pour ce cas, tu peux lancer la mise à jour dans un screen si quelque chose plante, tu réouvres konsole fraichement mise à jour et récupère le screen avec "screen -dr".
Je suis en rolling release depuis 2003 (gentoo), je n'ai jamais eu besoin de rebooté. En 20ans, j'ai évidemment eu quelques transpirations suite à des màj foireuses, mais c'était à chaque une mise à jour majeure (upgrade de xwindows, de KDE, noyau avec prb de drivers graphique).
À l'opposé y'a pleins de fois ou ça marche bien: J'ai upgradé récemment un portable de kde 5 en 6beta (avec les versions compilées depuis git tant qu'à faire) à ma grande surprise j'ai pu faire ça depuis konsole sans prb particulier, tout en glandouillant avec Firefox sur le net.
C'est marrant de voir des éléments se recharger à la nouvelle version au fur et à mesure de la compilation :) Bon c'est un portable qui ne contient aucune donnée perso, je n'aurais pas fait ça sur ma machine principale (enfin j'aurais lancé emerge dans un screen, et éviter de faire des trucs trop important en même temps)
#2.11
L'idée, c'est de pouvoir mettre tes grands parents devant une Fedora tout en sachant que ça ne cassera pas et qu'ils ne t'appelleront pas régulièrement en panique.
À nous de voir si nous souhaitons ou non démocratiser le libre (qui a une carte à jouer dans la sobriété que nous sommes censés viser).
#3
Le bon exemple c'est le wifi 6E avec Win10 : une carte Intel compatible wifi 6E reste bloqué en wifi 6, car pour avoir le wifi 6E il faut obligatoirement etre sous windows 11.
Et c'est purement une limitation logicielle, car sur des vieilles versions du drivers Intel le wifi 6E était fonctionnel
#4
#4.1
#4.2
et tu peux toujours utiliser minitool pour controler et choisir les mises a jour que tu veux installer, et zapper les autres.
#5