Reprise du message précédent :

J'utilise ce script car je n'aimais pas vraiment l'idée d'associer mon compte à mon PC. Idem pour les comptes utilisateurs, j'utilise systématiquement un compte local.

Au début ça fonctionnait très bien, mais je n'avais pas vu que le script n'était plus à jour (aucune mention sur le github)  puis ça a été repris par un autre dev car pour la petite histoire le dev orignal est malheureusement décédé.

D’ailleurs, il n'est plus réellement obligatoire car j'ai pu dissocier mon compte après coup, et je peux toujours recevoir les build. Il semble qu'il ne soit nécessaire que pour l'inscription ou pour changer de branche, c'est pas mal comme système.

https://i.imgur.com/kYcMzYr.png

J'ai tendance à vite râler pour un rien  

Après associer un compte sur une machine de test, je ne trouve ça pas trop intrusif.

C'est pas faux.

Les futures builds "dev" pourraient être estampillées 22*** à partir de cette semaine et plus 21xxx.
 
Source : Tweeter de Wzor

Le principe du programme Insider, c'est de tester en avant-première les futures évolutions de Windows 10, valider son fonctionnement et ses applications dessus et de remonter les remarques/bugs via Feedback.
Or pour remonter ces remarques et erreurs, il faut bien un compte ! d'où le fait qu'il soit nécessaire ...

Ce n'est pas juste une limitation technique ni "intrusif", c'est au centre même du programme !
Comme la télémétrie, d'ailleurs.
 

C'est pour ça que je disais que c'est contraire au principes même du programme Insider.
Si tu n'es pas d'accord, reste avec un compte local sur une installation standard !

Je suis bien d'accord que c'est le but du programme. Mais perso, je n'ai pas le réflexe de remonter les bugs (faudrait-il déjà que j'en croise un, ce n'est pas arrivé pour le moment...) Je me contente simplement de tester les nouveautés ou de m'habituer à la nouvelle organisation de l'interface.

Ça ne date pas de 10 d'ailleurs, pour avoir testé 7 et un peu 8 durant leur phase beta c'était exactement pareil. Donc dans mon cas avoir mon compte associé ne sert pas à grand chose.

Nouvelle build ce soir dans le canal Dev ! Chose interessante, ce n'est plus une build de la branche rs_prerelease que l'on reçoit, mais une de la branche co_release (donc la branche définitive de "cobalt" le nom de code de la future version)
 
Cette build numérotée 21354.1 apporte des nouveautés au niveau de flux d'actualité et de la gestion automatique de la luminosité de certains écrans.
Paint et l'Outil de capture d'écran sont désormais disponible sur le Store.
Le nouveau dossier "Outils Windows" accueille de nouveaux programmes auparavant stockés dans les dossiers "Accessoires Windows" et "Outils système Windows".
 
Le panneau de paramètre accueille quant à lui un nouveau module Webcam totalement réorganisé pouvant permettre de piloter indépendamment des webcams locale ou sur IP.
 
Pour les changements, le chemin d'accès aux systèmes WSL par défaut dans l'explorateur devient "\\wsl.localhost\\" au lieu de "\\wsl\\". D'autres changements moins importants concernant le changement des heures d'activités ou l'usage du PC sont également de la partie.
 
Pour les corrections de bug, il y en a plein... mais deux sont à mettre en avant :
- La correction du crash pendant les jeux
- La correction du GSOD SYSTEM_THREAD_EXCEPTION_NOT_HANDLED au redémarrage ou à lextinction dans les builds précédentes.
 
https://blogs.windows.com/windows-i [...] ild-21354/
 
PS: L'ISO de la 21354.1 est également disponible

Est ce que quelqu'un a vu passer dans le canal dev un réglage permettent la bascule automatique vers le monde sombre?
Ou il faut toujours passer par une application tierce?

Pour faire clair pour au niveau des canaux :
 
#FE_RELEASE = 20xxx ... 21H1
#CO_RELEASE  = 21xxx ... 21H2
#RS_PRERELEASE = 22xxx ...?

Non, ça serait trop simple.  
 
Vibranium : (ca aurait du être Chromium vu qu'on suit la liste des elements pour les versions de Windows mais le nom était déjà utilisé   )
vb_release = 20h1, builds 18836 à 19041 (finale),  dernière version sortie pour PC.
 
20h2 (19042) et 21h1 (probablement 19043) sont des cumulatives pour vb_release sans changer de version.  
 
Manganese :  
mn_release (19536 à 19460) n'a jamais eu de version finale sur PC. Il a servi principalement en interne à finir la première version de Windows 10X (pré-covid, qui devait tourner sur 2 écrans).  
 
Iron:
fe_release (20150 à 20329+++) n'a jamais eu de versio finale sur PC grand public. Il a servi à finir la nouvelle mouture de Windows 10X (qui fonctionne sur tout type d'appareil).  
 
 
Il est également mis à la disposition des versions serveurs de Windows, dont la beta de la prochaine version est sur cette branche.  
 
 
 Cobalt : CO_RELEASE de 21277 à maintenant (dans le canal insider dev).  
 
Devrait être la prochaine version qui sort pour les PC de bureau (21H2, sun valley) plus tard dans l'année.
 
RS_prerelease est le canal dev de Windows.  
 
A chaque fois qu'ils décident de freezer globalement une version niveau features, ils forkent vers un canal release et font sauter rs_prerelease d'un grand nombre de build.
 
 
RS_PRERELEASE---               --------------            ------------              --------
                           \VB_RELEASE              \MN_RELEASE       \FE_RELEASE     \CO_RELEASE

 
Je suis d'accord mais comment tu peux dire que les builds 21277 et > sont dans la branche "CO_RELEASE" alors que l'on voit "RS_PRERELEASE" ici :
 
https://blogs.windows.com/windows-i [...] ild-21277/
 
et ici :
 
https://msbuilds.rg-adguard.net/?build=21277.1000
 
Il y a que les builds 21353.1 et 21354.1 qui sont, pour le moment, dans la branche "CO_RELEASE".

Je simplifie.
 
Par rapport à mon schema, j'ai considéré chaque rs_prerelease avant la release qui lui correspond comme faisant partie de celle-ci vu qu'il y a une continuité dans les numéros de build.  
 
Sinon, tu dois séparer les rs_prerelease entre chaque saut.  
 
RS_PRERELEASE avant vb >> saut de 500-1000 build pour finir vb >>  RS_PRERELEASE AVANT MN  >> saut ....
 
Les RS_PRERELEASE avant une release fonctionnent de facto comme une alpha de cette release.

 
 
Sur la dernière (21354) je n'ai rien vu à part le truc pour la lumière bleue.

 
   
 
Branche "rs_prerelease" non utilisée en cas de maj mineure (par ex pour les majs 19H2/20H2 et pour finir la prochaine 21H1).
 
Si je recapepete :
 
Windows 10 "RTM" de juillet 2015 : branche "th1"
10 1511 : branche "th2"
10 1607 : "rs1_release"
10 1703 : "rs2_release"
10 1709 : "rs3_release"
10 1803 : "rs4_release"
10 1809 : "rs5_release"
10 19H1 : "19h1_release"
10 19H2 : "19h2_release_svc_refresh"
10 20h1 : "vb_release"  
10 20h2 : "20h2_release_svc_refresh"
 
La version 21h1 risque de sortir sous la branche "21h1_release_svc_refresh" si on prend le schéma de la maj 20h2.
 
La branche "vb" aka vibranium changera au moment de la future maj majeure (pour la 21h2 ?) pour "co_release" aka Cobalt.  
 

C'est le Patch Tuesday Day !
 
En plus des sempiternelles corrections de bugs et failles de sécurité, les adeptes du canal Release Preview peuvent désormais apprécier la 21H1.
 
https://blogs.windows.com/windows-i [...] -channels/

 
Ça avance donc !
 
Merci pour la cocotropiconews  

Nouvelle build disponible dans le canal dev ce soir !
 
Etant donné que nous ne sommes plus sur la branche rs_prerelease, les nouveautés vont s'amoindrir.
 
Avec cette build 21359.1, la seule vraie nouveauté à noter est la disponibilité d'une nouvelle option pour redémarrer son PC via le menu démarrer. Elle est appelé : "Redémarrer mes logiciels après connexion".
Elle activera l'option qui existe déjà dans les paramètres de Windows.
 
A part ça, des corrections de bugs...
 
https://blogs.windows.com/windows-i [...] ild-21359/

 
Alors dans ce cas où est Sun Valley ????!!

Ils ont toujours dit que ce serait pour 21H2 (voire 22H1, d’après les derniers bruits de couloir ?), pas 21H1.

 
Je sais bien que ce n'est pas pour la 21h1. Mais on sait que le code de la 21h2 serait finalisé en juin donc il ne reste plus beaucoup de temps pour implémenter de gros ajouts !

Il est effectivement fini pour l'ajout de grosses fonctionnalités. Par contre, le thème et les icônes relèvent du "peaufinage" et peuvent encore arriver jusqu'à la finalisation en Juin.
 
D'ailleurs, il ne faudra pas s'attendre à un chamboulement visuel de ce coté là... (coin arrondis pour les fenêtres et menus, nouvelles icônes un peu partout... Enfin presque, il ne restera que le dossier "Offline Web Pages" dans C:\Windows qui arbore un style Windows 95   )

Depuis la catastrophe longhorn il y a 15 ans, ils activent très rarement des trucs "early" dans les beta publiques.  
 
Ca arrive quand c'est proche de la finalisation.

Nouvelle mise à jour cumulative pour dans les canaux bêta et RP. La révision 962 apporte le flux d'actualités (qui était de base dans le canal dev) à la 21H1.
 
De même, la màj apporte le correctif contre la corruption du système de fichiers NTFS.
 
https://blogs.windows.com/windows-i [...] -channels/

Nouvelle build ce soir dans le canal Dev qui nous offre la 21364.1 au téléchargement.
 
Côté nouveautés, les utilisateurs de WSL peuvent désormais faire fonctionner les logiciels graphique directement dans Windows. En effet, les logiciels installés apparaitront dans le menu démarrer, seront disponible dans la barre des tâches (avec une petite icône Tux) avec une compatibilité graphique via le GPU de la machine pour les logiciels utilisant de la 3D.
 
Concernant le gestionnaire des tâches, ce dernier permet d'afficher tous les processus (de façon détaillée) des dernières versions de développement de Microsoft Edge (Dev & Canary), il permet d'identifier plus rapidement un onglet (grâce aux favicons) ou un processus interne (celui du GPU ou autre) qui déconne pour le fermer ou le redémarrer.
 
De même, l'ajout une mode Eco, permet à un processus gourmand de céder sa place si une autre tâche a besoin des ressources du PC.
 
Pour le reste, quelques changements ou améliorations et différentes corrections de bugs.
 
https://blogs.windows.com/windows-i [...] ild-21364/

Sympa aussi. Merci

 
Cela peut être très pratique pour du dépannage et éviter de devoir démarrer une machine linux.

Tiens, il y a encore quelques jours, un certain blogueur a encore ressorti son fantasme d’un prochain « Windows 11 » (qui serait un Linux maquillé façon macOS, avec pleine compatibilité avec les applications Windows grâce à un WINE amélioré bénéficiant des vraies API Windows). Avec cette dernière annonce sur la prise en charge des applis graphiques Linux par WSL, vous confirmez que ce vieux rêve d’un « Lindows bis par MS » n’a plus la moindre raison de voir le jour un jour, vu que WSL permet désormais d’utiliser absolument toutes les aplis Linux, CLI comme GUI, et même celles nécessitant les fonctionnalités 3D des cartes graphiques ? Il est assez « closquard » (têtu), comme on dit chez moi, et refuse absolument d’en démordre…

Il n'a pas tort par rapport à la dette technique qu'il faudrait traiter plus "violemment" à mon avis.
La rétrocompatibilité a ses limites quand on veut évoluer rapidement.
 
Par contre, un Windows basé sur un noyeau Unix, pourquoi faire ?
Les distributions Unix/Linux le font déjà très bien, Windows et Microsoft n'apporterai rien.
En tout cas pas plus que ce que Microsoft apporte déjà à la communauté libre (c'est le premier contributeur open source )...
 
Et le fantasme MacOS ...
Ce n'est qu'un fork de BSD surcustomisé et pas fait du tout pour être utilisé tel quel comme un Linux.
 
D'ailleurs, qui se soucie du noyau ?
C'est tout l'écosystème qui est important.

Sûr. Quand on voit encore les soucis qu’ont ceux qui passent par le module Netplwiz (qui n’est visiblement plus maintenu) pour s’éviter d’avoir à taper leur mot de passe de session… Ou, autre exemple moins gênant à première vue : la prise en charge des archives Zip par l’Explorateur, basée sur un code fourni par un tiers vieux de plus de 20 ans et qui n’a plus vraiment été maintenu depuis la sortie de Windows XP.
 

Il ne le cite qu’à titre d’exemple, pour schématiser son OS fantasmé : noyau Linux (ou du moins Unix) + couche de compatibilité Windows.
 

Justement, il aimerait que les devs se concentrent un peu plus sur le segment qui fait défaut à Linux, dans son idée : le monde de la bureautique et l’accessibilité des systèmes et logiciels Linux et libres aux gens peu familiers de l’usage d’un ordinateur au-delà des fonctions les plus basiques (il aimerait que ceux qui galèrent déjà avec Windows galèrent moins avec Linux, pour permettre enfin à ce dernier de décoller et gagner en présence sur les PC destinés au grand public ; oubliant quand même que pour la plupart des gens à la maison, le PC n’est jamais qu’une sorte de console de jeu un peu plus polyvalente qu’une PS4/5 ou une Xbox, en tout cas chez la plupart de ceux qui sont des générations post-boomers).

A coté de ça, la rétrocompatibilité, c'est un des trucs qui a fait le succès de Windows en entreprise

Quand je vois les merdes et leurs conséquences chez les clients où j'interviens, je n'appellerai pas ça un "succès"

[HS]
C’est pas Google avec Android entre autre?
[/HS]

Si ça n'a pas changé depuis 2018, Microsoft a le double d'employés par rapport à Google contribuant activement aux projets Open Source.
https://www.techrepublic.com/articl [...] %20Google.
 
Je dirais que ça s'est d'autant plus accéléré depuis le rachat de GitHub (2018), sachant qu'ils étaient déjà dans le TOP 20 des contributeurs au kernel Linux...
Et avec l'intégration de plus en plus poussée cross-OS (drivers pour Linux, WSL pour Windows , etc. ...) et les besoins pour Azure, ça ne va pas s'arrêter là.

 
le fantasme a la con
 
ca n'a aucun interet  
 
ils puent tellement la defaite qu'ils esperent un Windows sous linux pour enfin avoir des softs correct sur leur ubuntu/fedora/arch/autre
 
Je vois pas du tout ce que ca apporterait d'avoir un Windows linuxisé.
Windows fait tres bien ce qu'on lui demande de faire
Linux fait tres bien ce qu'on lui demande de faire.
 
Je trouve Linux a chier en desktop, j'utilise pas. Je trouve Linux super en serveur, j'utilise  

Merci

Arch marche très bien sur mes ordis, chez moi (99% du temps, disons).  
 

J’avoue que je comprends pas pourquoi il tient absolument à ce que les choses tournent ainsi à un terme de… 10 ans maxi, on va dire ? Il dit que c’est pour « se débarrasser d’une certaine dette technique » comme l’a jadis fait Apple au moment de passer des Mac OS classiques à Mac OS X, mais il est loin d’expliciter ce qu’il entend derrière ça, ni en quoi ce serait impératif pour Microsoft de donner un remplaçant à Windows basé sur du Linux. À moins que ce ne soit juste par méconnaissance complète des travaux qui ont été opérés sur le noyau depuis la branche 6.x, ce qui ne me surprendrait pas.

Je penche aussi en cette faveur. S’affranchir du développement du noyau en prenant le kernel Linux ne ferrait qu’augmenter les coûts de développement car il faudrait alors rentre compatible toutes les applications avec ce dernier. La vrai fausse bonne idée.

Et également le fait que le noyau NT est a des années lumières devant le noyau Linux niveau stabilisé.  
 
Pour vraiment faire planter windows, il faut y aller depuis Vista ou installer un driver pourri.

À des années lumières de Linux, je ne pense pas. Équivalent, sans doute.

Yep. Dans les 2 cas, le problème vient souvent d'un tiers foireux. Typiquement un driver pourri ou du matos défaillant

Pas grand chose à se mettre sous la dent ce soir...
 
Dans le canal Dev, la 21364 obtient une nouvelle CU pour tester les tuyaux après la précédente pour les mêmes raisons. Cela fait donc augmenter la révision à 1011.
 
https://blogs.windows.com/windows-i [...] ild-21364/
 
Pour la 21H1 dans le canal bêta et RP, une nouvelle CU (révision 964) corrige des GSOD
 
https://blogs.windows.com/windows-i [...] -channels/