Une drôle d’annonce de Microsoft, qui a présenté la nouvelle officiellement dans une note technique. Il est pourtant possible d’installer la version web de Teams depuis des mois sous Linux.
La communication prend cependant un nouveau sens, car l’éditeur affirme que cette PWA va permettre de réduire l’écart entre Linux et les autres plateformes, qui bénéficient d’applications « desktop » beaucoup plus complètes.
Effectivement, elle apporte les mêmes fonctions que les clients pour Windows et macOS. Elle est utilisable comme une application classique, avec sa propre fenêtre, sans le « Chrome » du navigateur. Elle aura même son propre raccourci dans un dock ou une barre des tâches.
Mais ce qui est gagné d'un côté est perdu de l'autre. D'une part, elle n’est annoncée compatible qu’avec Chrome et Edge, déjà un problème en soi puisque l'utilisation dans un autre navigateur ne bénéficiera d'aucun support technique.
Ensuite, le message envoyé aux entreprises est d’abandonner l’application pour se diriger vers cette PWA. Mais une PWA est bien moins pratique à administrer de manière centralisée qu’un paquet deb ou rpm, sans parler des restrictions sur les navigateurs pleinement reconnus.
Microsoft sait parfaitement manier Electron, comme elle l’a très bien montré avec Visual Studio Code. On se demande donc pourquoi il est si difficile de proposer une application correcte qui emballerait simplement la version web, en offrant ainsi toutes les fonctions du service, tout en gardant les avantages d’un paquet pour l’administration.
Commentaires (106)
#1
Mouais … il y a déjà ça pour Google Chat et c’est pas fou fou. C’est une fenêtre Chrome sans la déco Chrome :/
#2
Euh je ne pense pas que ces navigateurs soient dispo sans bricoler sous Linux :)
Ils se sont cognés la tête ?
Ex avec Debian (c’est pareil avec ubuntu) : https://packages.debian.org/unstable/web/
=> je ne trouve que chronium et firefox en navigateurs connus
pour installer edge ou chrome faut aller bricoler la source list :)
#2.1
Alors je ne suis pas un expert en Linux, mais télécharger par exemple un .deb de Chrome ou Edge est très facile , sans modifier les depositeries.
#2.2
Si tu passes par les boutiques intégrées effectivement, mais quand tu vas sur les sites officiels de Chrome et Edge, tu as bien Linux dans les téléchargements, avec à chaque fois un deb ou un rpm
#2.3
Tout à fait sauf qu la philosophie des distributions Linux, c’est plutôt de récupérer les logiciels depuis le dépôt de la distribution. Récupérer des logiciels depuis différents sites web, c’est plutôt une philosophie de gens sous Windows
#2.4
Oui, carrément, quand tu vois que la commande winget va juste récup les exe / msi sur les URLs des éditeurs, ça fait un peu peur pour un gestionnaire de paquet
#2.5
Tu n’as jamais installer un outil professionnel, en particulier ceux avec une licence d’utilisation (celle qui coûte un bras), sous Linux. On regrette très vite les install de Windows tant c’est archi dégueulasse (au moins sous Windows, c’est déclaré dans les “Programmes” et donc désinstallable via les outils systèmes).
#3
“elle n’est annoncée compatible qu’avec Chrome et Edge”…
Avec FF, on n’avait déjà en gros accès qu’au chat. Quand on cherchait à utiliser les fonctions audio/visio, on se voyait dire que navigateur pas compatible et orienter sur Edge/Chrome. Essai de chromium non concluant, j’imagine idem chrome… Et Edge, jamais réussi à faire fonctionner le micro. L’appli proposée auparavant plantait.
Ce qui est dommage, à la base, c’est de se voir imposer par les employeurs des outils absolument pourris (Teams est un foutoir sans nom, ils ne sont même pas fichus d’indiquer des status fiables) et que microsoft n’est même pas fichu de coder propre/portable, aussi la raison pour laquelle toute sortie du duo x86+windows est jusque là un échec (cf leurs multiples tentatives désespérées avec Qualcom)… et qu’ils sont aussi très bons pour transformer l’Or d’un rachat en plomb: Cf Skype, pour rester dans le domaine…
#3.1
Ça marche vraiment pas techniquement ou un spoof user-agent et ça fonctionne ?
Vu que tu as plein de site / webapp “non compatible” Firefox et quand ton Firefox leurs fait : “Coucou, je suis Chrome” tout fonctionne, je me pose la question
#3.2
Oui en modifiant le UserAgent ça passe très bien, il y a même un plugin FF qui le gère tout seul uniquement sur Teams : https://addons.mozilla.org/en-US/firefox/addon/teams-phone-fix/
#4
Sans compter qu’Edge a qq pb de stabilité quand on fait l’effort de l’installer… et qu’après un essai de l’appli Teams jusque là proposée sous Debian 11, qui ne se lance pas complètement voir plante.
Ce qui fonctionne en l’état le mieux pour moi, c’est la version web de Teams sous FF en s’en tenant au chat. Le reste ne fait qu’étaler la crasse incompétence de Microsoft et ses choix catastrophiques pour développer de l’applicatif.
#5
Leur appli lourde Linux était clairement inutilisable à cause de bêtes bugs de gestion du micro qui se faisait “mute” sans raison, et qu’on ne pouvait pas “unmute”, pas très pratique quand on veut faire une visio…
#5.1
ah non c’est pareil sous windows ou iphone je t’assure ! Le pire c’est qu’avec un Jabra, ça inverse une fois sur deux le fonctionnement de la LED mute sur le case : la LED mute est allumée mais le micro est ouvert !
#6
#7
Ils sont également dispos sur Flathub (Chrome / Edge).
Puis pour des applications propriétaires dont on ne sait pas trop ce qu’elles font, ce n’est pas plus mal qu’elles soient conteneurisées 🙂
#8
Le plus curieux est que j’utilisais la version web (via Vivaldi ^^) sans pb jusque là; l’application étant trop instable et trop gourmande en ressource sous Linux.
Le mieux aurait été de laisser tel quel …
Dans mon cas, on a migré vers une autre solution ce qui au final m’arrange ^^
#9
Le truc qui fait vomir: Traîner toutes les dépendances sur un OS qui sait parfaitement les gérer proprement et rajouter une couche de conteneur pour assurer de couper les ponts/simplifier le test sous de faux prétextes de sécurité.
Bref, la gabégie historique de windows qui n’a jamais géré proprement les dépendances poussée sous Linux, en pire.
#10
Ah, autant user-agent-switcher me sert parfois à beurrer les lunettes de sites refusant totalement de s’afficher sous FF, autant là avec cette situation de fonctionnalités amputées je n’avais pas pensé à tester.
Mais bon, c’est pas les chat/visio qui marchent sans toute cette lourdeur qui manquent… Se voir imposer cela en entreprise et dont on ne voudrait pas en usage perso, c’est vraiment la merde.
#11
C’est juste une blague le support de Chrome et Edge uniquement sous Linux…
Par défaut la plupart des Distrib intègre FIrefox, et comme dit dans plusieurs commentaires, Chrome et Edge ne sont pas dans les repo par défaut, il faut ajouter des repo, ou dl direct les deb s’ils existent…
Juste n’importe quoi…
Sinon:
C’est ironique non ?
#11.1
Il est bon de rappeler que FIrefox a décidé de ne pas supporter pas les PWA. Donc déjà, ça part mal pour utiliser la PWA de Teams avec Firefox.
#11.2
Oui, en effet, ça doit pas aider, mais du coup, pourquoi Microsoft n’a pas continuer à faire évoluer le paquet Deb, plutôt que d’aller sur du PWA sur Linux, avec uniquement Chrome et Edge…?
J’imagine que c’est pour des raisons de facilité…
D’ailleurs, est-ce que cela fonctionne avec Chromium ?
#11.3
Je pense en effet que c’est surtout une histoire de facilité, pas besoin de gérer 36 plateformes différentes, surtout que pour linux, il faut gérer à la fois les distribution et les versions.
Je ne sais pas du tout. La plus grosse limitation qui pourrait me venir en tête ça serait l’utilisation de codec non libre qui à mes souvenirs ne sont pas activé par défaut dans chromium (il y a une manip à faire).
#11.4
A ma dernière tentative, Teams était utilisable avec Vivaldi.
Par contre, ce serait bien que Microsoft dégage la détection de la présence …
Sur la version Web (avec Edge), même en indiquant que je suis en “occupé” jusqu’en 2024, je passe de temps en temps en occupé alors que je suis bien en train d’utiliser le PC.
Application en mousse.
#12
Non, le prétexte, c’est la reproductibilité et la portabilité. Perso, je n’aime pas flatpak et j’essaye d’éviter de l’utiliser tant que faire se peut, mais parfois ça dépanne quand la distribution a certaines librairies dans ses paquets standards compilées avec des options qui rendent l’usage le soft partiellement ou complètement inutilisable.
#12.1
Ou alors, tu compiles à partir des sources si le paquet officiel ne te convient pas. Ça prend moins de place sur ton disque et ça ne fait pas des systèmes parallèles d’applications sur ton système.
#13
#14
Quand il faut en arriver là pour pouvoir utiliser correctement un logiciel, je pense raisonnable de se demander si on est vraiment obligé d’utiliser le logiciel.
#15
Non, les distributions ne savent pas faire.
Sur une Debian stable qui ne propose même pas GTK 4, pourtant sorti il y a plusieurs années, tu fais une croix sur toutes les applications récentes. C’est également valable dans l’autre sens. Arrive un moment où les distributions considèrent que c’est trop vieux, plus maintenu et qu’il vaut mieux s’en débarrasser. Et tant pis si ça ne te permet plus d’utiliser une vieille application qui répondait à tes besoins.
Linux est à des années lumière de la compatibilité descendante d’un Windows.
Flatpak a également un autre avantage, c’est qu’il permet de faire le travail une fois et de toucher ensuite l’ensemble des distributions, ce qui permet d’avoir des paquets pour tout plein de petits projets qui n’intéressent pas les mainteneurs de distributions ou des paquets pour des projets super récents qui ne les intéresseront (potentiellement) que bien plus tard.
#16
Remplacer la librairie fournie par le paquet officiel de la distribution par un truc compilé à la main? Pas trop pérenne comme approche, surtout si la librairie est utilisée par d’autres softs et que la version de la distribution est en mode stabilisé+tas de backports sécurité.
Enfin bon, chacun est libre de mettre le boxon dans son système comme il veut, mais je réserve ce genre de bricolage pour l’expérimentation, pas pour les systèmes que j’utilise au quotidien …
Perso, je préfère garder les problèmes du genre séparés du reste de l’OS et éviter de propager la misère: flatpak pour les applications desktop, conteneurs OCI pour la partie serveur.
#17
Vas-y, amuse toi à compiler Microsoft Edge…
Puis pour compiler, il faut installer tout un environnement de développement (compilateur pour chaque langage, différents outils, bibliothèques de développement…) ce qui va également te bouffer de la place et dont il faudra ensuite récupérer les mises à jour.
Tout ça pour économiser un peu d’espace disque, alors que les SSD dédiés au système d’exploitation sont de plus en plus gros et qu’on se retrouve avec des centaines de Gio, pour ne pas dire des Tio d’espace libre, bêtement inutilisés.
#18
Ah, tu penses à des trucs du genre Debian qui a retiré le support rtsp de VLC (pb de licence, visiblement, mais qui ne semble émouvoir que Debian) alors que c’est ce qui est le plus utilisé sur les caméras IP.
Mais bon, le cousin snap (de mémoire) est visiblement tout sauf reproductible et portable: Long comme un jour sans pain à lancer et très instable: Si on en lance deux, c’est 2⁄3 de chances de planter toute l’interface graphique et devoir faire ctrl/alt/f1+login console, killall vnc, ctrl/alt/f7.
Pour le truc qui “dépanne”, franchement, je dirais plutôt que le concept vicié de base tombe plutôt “en panne”…
#19
On parle de Teams là. Pas le genre de soft que t’utilises pour le plaisir mais surtout parce que t’as pas le choix vu que toute ta boite est dessus.
#20
Oulà! Si à la fin tu peux avoir une chance de prendre moins de place sur le disque (qui en général n’est pas à cours de place à causes applis mais plutôt à cause des données), pour pouvoir compiler il va te falloir jusqu’à 10x la taille du fichier final!
Entre les sources, les sources des dépendances, les fichiers objets, les fichiers de symboles et autres méta données de compilation/débogage… utiliser 4Go pour compiler 250Mo d’exécutables , c’est pas si rare.
Pour compiler une ROM android de 4Go, il me faut de mémoire 100Go (et je prune bien les sources)
#21
Si la boite utilise Teams et à des postes Linux, c’est qu’elle a eu une erreur de raisonnement à un moment.
#21.1
Ah bon ?
Elle peut avoir une majorité de postes souis Windows et certains sous Linux.
#21.2
Bah non, souvent dans une boite tu vas avoir des postes sur plusieurs OS. Il suffit que les postes bureautiques soient sous Windows et aient besoin d’Office. Avec 10 balles par mois et par salarié t’as Office / OneDrive / une boite mail de 50 Go par salarié et Teams est inclus dans tout ça. Bien sûr la gestion des utilisateurs et de l’authentification de tout ça est centralisée.
Donc même en trouvant que Teams est bien moisi, je peux comprendre que t’aies pas envie de rajouter un truc externe (auto-hébergé ou non) qui te coûtera plus cher, sera potentiellement pas intégré avec ton authentification, ne sera pas intégré avec Office parce que t’as quelques postes de devs sous Linux. Rien que Slack on est aussi à 10 balles donc tu doubles la facture juste pour le chat alors que tu paies déjà pour un produit, même si il est moins bon.
Si tu pars sur de l’hébergé maison ça te coûte encore plus cher en infra et en temps de travail et c’est à toi de gérer la merde le jour où l’outil tombe en rade, que tu sais pas pourquoi, que le gars qui gère ça est malade, que toutes les équipes se retrouvent au ralenti … Bonus si tu mets pas à jour l’outil et que tu te fais poutrer toutes tes conversations internes dans la nature.
Je suis d’accord que Teams c’est de la merde. Mais si dans ta boite t’as 100 devs/produit, 100 sales et 100 marketing, t’as quasiment 2⁄3 de la boite qui peut pas se passer d’Office. Et je suis gentil je compte pas les non tech dans le département produit. Donc tu prends le package complet chez MS et tu fais avec les défauts.
#21.3
Oui, on en revient à un manque de vision à long terme. Un exemple de à quoi conduit de mettre tous ses oeufs dans le même panier : https://www.lefigaro.fr/secteur/high-tech/le-non-de-collectivites-locales-a-microsoft-20221012
#21.4
Un manque de vision à long terme ?
En faisant en sorte qu’une entreprise se concentre sur son business au lieu de multiplier les outils IT pour le plaisir de faire de l’IT ?
En faisant en sorte que des fonctions supports n’imposent pas des coûts supplémentaires pour toute l’entreprise sur des politiques qu’elles-mêmes décident ?
Tout ça pour que 3 devs dans leur coin ne lancent pas Linux dans une VM pour travailler comme tout le monde avec des outils comme tout le monde ?
Si “rationnaliser les dépenses” et “éviter de payer en double” pour un usage équivalent c’est manquer de vision à long terme, je pense qu’on n’a pas la même base en stratégie.
(Bon, rien que “mettre tous ses œufs dans le même panier” est déjà révélateur en soit)
#21.5
Tout dépend de la taille de la boite mais lorsque tu es une grande entreprise, oui ça s’appelle un manque de vision à long terme de tout sous-traiter plutôt qu’internaliser les fonctions essentielles. D’une part ça coûtera plus cher à long terme et d’autre part, les données sensibles (commerciales ou autre) sont gentiment envoyés à l’étranger.
#21.6
Je suis actuellement en presta chez un gros compte dont la SI ne gère que du Windows/MacOS. Et utilise la suite Office, donc Teams.
En interne les dev sont sous Mac. Les presta nous sommes une majorité à être sous Linux. Là le choix du client est volontaire et affirmé : le SI ne veut pas avoir à gérer de Linux.
Tu crois sérieusement que le client va faire une exception juste pour nous et mettre une alternative en place pour une petite dizaine de postes sous Linux (et QUE des presta) ?
Et ce n’est pas une manque de vision à long terme ou quoi que ce soit : ils ont leurs besoins et ils ont acté certains choix pour l’interne. Aux presta de se plier à ça (et ça se comprend).
#22
Teams peut être imposé par un gros client sur un projet spécifique.
#23
Bin tiens!
En même temps, personne n’avait souhaité qu’après gnome 2 le projet régresse en prenant en prime ses utilisateurs pour des abrutis… Cinnamon m’a aidé à le supporter depuis 10 ans, mais comme le mainteneur Debian a fini par lâcher l’affaire et virer KDE, la 11 sera sans doute pour moi ma dernière installation basée GTK.
Car on est dans un modèle de compatibilité de sources et pas de binaires. Le second, c’est la lourdeur croissante d’un windows et une approche du soft globalement digne des lanceurs de la Nasa: On laisse tout ce qui a priori ne sert plus à rien, même si le poids à un coût énorme, de peur d’effets induits destructeurs (vibratoires, pour les fusées). Et un jour on finit par voir débouler un SpaceX…
Euh… Faudrait voir pas confondre les dépôts Red-Hat et ceux de Debian. Pour le cas des trucs tous neufs, ça leur laisse le temps de se stabiliser. Et comme c’est tout neuf, on n’aura pas de gros pb à les générer si on veut les utiliser. Ça permet en prime de se rendre compte des dépendances qui vont au delà de ce que nécessite l’installation d’un paquet type “build-essentials”. Et donc de savoir si on a un truc plus ou moins bien fichu de ce point de vue: Mon petit doigt me dit d’ailleurs que si plus de nouveautés n’abusaient pas sur les dépendances évitables, on les retrouverait plus vite dans les dépôts car cela ferait moins de boulot (de merde) pour les mainteneurs!
A un moment, ce foutoir de dépendance c’est la ruine de ce qui a fait ses preuves… Et devoir avoir une machine avec 16GB de DDR pour faire tourner qq applis, vu que les doublons foutent aussi en l’air une bonne part de l’intérêt de la gestion de la mémoire virtuelle niveau lib partagées.
#24
Certes, mais choisir d’utiliser Teams, c’est volontairement exclure les postes Linux de la solution. C’est pas comme si il n’y avait pas d’alternatives ou alors je suis pas au courant de la fonctionnalité de la mort qui serait uniquement présente sur Teams.
#24.1
En effet, il y a pas mal d’alternatives à Linux, sans aucune fonctionnalité de la mort uniquement présente dedans, pour avoir un standard groupe rationnalisé autour de Windows, pour diminuer la charge de travail & les coûts pour quelques exceptions.
#24.2
“Chef on a un contrat de service et une TMA avec Microsoft, si ça merde on pourra dire que c’est la faute au prestataire”, voici la fonctionnalité exclusive à Teams en entreprise.
#25
Dans les grands groupes, la DSI se préoccupe rarement de tout le monde. Ils ont leur vision, et si certaines équipes sont sous Linux, tant pis pour eux. Ou plutôt : on leur dit que c’est supporté sous Linux, le .deb existe.
#26
En même temps, est-ce bien le rôle d’un navigateur… de doublonner un OS en temps qu’environnement d’exécution applicative?
Pour le coup, même si c’est pas forcément toujours la plus élémentaire logique qui s’impose matière technique, difficile de donner tords à Mozilla.
#26.1
SI c’est pour avoir à la place une appli à base d’Electron, autant avoir une PWA qui utilise le navigateur déjà installé.
#27
Ah c’était pas que moi alors
#28
Si tu ne modifie pas le fichier source.list tu va vite te retrouver avec une jambe de bois vu que tu ne pourras pas bénéficier des mises à jour automatiques.
#29
Idiotie sans nom
contre laquelle vous pouvez voter ici
https://connect.mozilla.org/t5/ideas/bring-back-pwa-progressive-web-apps/idi-p/35#comments
Vous pouvez aussi tenter l’extension
https://github.com/filips123/PWAsForFirefox
#30
Le problème c’est qu’on a trop de “standards” d’application portable pour le moment: flatpak, snap et appimage (on va oublier Klik)…
Je pense que pour le coup, c’est juste ridicule puisque on cherche à rendre les choses portables et universelles, mais bon, il y a des leçons à apprendre de cette diversité et on y verra sans-doutes plus clair d’ici 5 ans… perso je ne serais pas contre de jeter tout cela et de partir sur un modèle OCI.
J’utilise souvent flatpack, parfois appimage et j’ai peu de soucis avec eux, moi ça me dépanne.
#31
Quand on a sorti firefox os en nous expliquant que les web apps allaient nous libérer, il est ridicule de ne pas supporter les PWA.
#32
Pourquoi ? Au hasard je dirais que Electron sert à palier l’absence d’application locale (en fournissant un runtime chrome pour avec appli) alors que Microsoft veut se débarrasser des applications locales et proposer seulement du 100% web… donc du PWA.
#32.1
Tu as d’autres exemples que Teams pour Linux ?
#33
Donc pour toi, chaque “grande entreprise” doit concevoir de 0 sa stack technique complète ? Où est-ce qu’on met le curseur ? On s’arrête aux OS ? Ou elles doivent aussi développeur leurs propres processeurs ?
Une entreprise de travaux publiques doit forcément construire toutes ses machines (grues, pelleteuses, camions …) et ses matériaux parce que c’est essentiel ?
Pareil, Air France fait ses propres avions ?
Exit donc les Valeo, Tetrapack etc etc qui se sont spécialisé sur une offre précise à destination des “grands entreprises” ?
C’est d’un non-sens stratégique et économique.
Qui plus est, ici, Microsoft ne “sous-traite” pas pour ces clients, pas sur la partie O365 en tout cas; c’est un fournisseur de service.
Marrant ça parce que les études de TCO/ROI vont à l’encore de cette théorie, et ce qu’est généralement ce qu’on reproche aux décideurs, de ne voir que la partie “réduction des coûts”.
A toi de choisir ton fournisseur avec un stockage des données dans le pays que tu souhaites.
Et quand bien même ça partirait à l’étranger. Soit, et ?
Quid de la question des téléphones portables ?
Même G. Poupard en est revenu sur la “souveraineté totale” de la France dans le cadre de l’IT; alors j’ai du mal à voir quelle “grande entreprise” pourrait s’émanciper complètement.
#34
J’attends de voir le bazar que sera de ne pas mettre ses oeufs dans le même panier:
… Payer les formations à tout le monde …
#35
Mauvais exemple, puisque les compagnies aériennes travaillent en collaboration étroite avec les constructeurs d’avions pour orienter les futurs développements.
Et l’équivalent ne serait pas que Air France fasse ses propres avions, mais plutôt qu’ils les achètent réellement plutôt que de les louer, et qu’ils en possèdent la maîtrise technique pour en réaliser l’entretien. Et en effet, ils font ça.
#36
Il y a plein d’entreprises qui le font pour des tas de sujets. Rien de choquant à ça dans le monde pro.
Maintenant, si tu veux t’offrir entièrement à Microsoft, libre à toi, mais ne te prévaut pas d’une vision long terme sur le sujet, ne dis pas que tu es agile, dis juste que ton objectif est de pratiquer la règle du moindre effort même si cela pose certains risques (que tu n’as pas pris la peine de mesurer parceque pffffff….)
#36.1
T’as oublié l’AD.
Un jour j’ai du installer samba 4 chez un client. J’ai explosé tous les jours de vendus. On m’a dit que ça me resservirait pour un prochain projet. J’attends toujours.
Mais bon c’est bien la décision qu’une collectivité locale serait capable de prendre…
#36.2
L’énumération vient du post que je citais… AD, ça peut être inclu dans la solution SSO… à côté de ça, il faut de toutes façons un processus de gestion des utilisateurs et des identités.
Perso, je suis un adepte de FreeIPA comme alternative à AD: ça marche plutôt correctement et ça ne laisse pas les systèmes linux sur le bord de la route.
#36.3
AD en tant que contrôleur de domaine n’est pas inclus dans le SSO.
FreeIPA utilise samba (et 389DS) pour sa partie AD. Y’a pas d’autre alternative.
#37
Nan nan, tu peux trouver les versions stables … qui mettent à jour toutes seules la liste des dépôts apt
#38
Pas forcément, vu à quel point le “web” est devenu applicatif, transformer un page web en application stand-alone n’est finalement pas si incohérent.
Electron ce n’est pas qu’une page web dans un navigateur, c’est aussi un serveur node.js et donc des services qui peuvent tourner derrière (et donc potentiellement des binaires comme dans certain module VScode). Electron permet donc de faire beaucoup plus qu’une PWA.
Dans le cadre de Team, à priori, ça se connecte déjà à un serveur, ça n’a donc pas forcément besoin d’un serveur local, PWA est donc effectivement suffisant dans les grandes lignes.
#39
Pour compléter : la 14 octobre 2025, un certain Windows10 va voir son support être arrêté.
Du coup, il va falloir passer à Windows11 (CàD Proc récent + tpm2 = mise à jour du parc + compte azure obligatoire même pour les versions Pro). Bref, les AD locales devront être copiées dans Azure (CàD la description complète de l’organisation de la boîte avec la liste des individus disposant des accès restreints etc …), donc copiées dans Azure pour assurer l’ouverture des sessions Windows en dehors du réseau d’entreprise. Toutes les infos stratégiques de l’entreprise chez MS, je pense qu’il va y a voir des responsables qui ne vont pas être d’accord avec la chose. Dans ma boite, nous avons des clients anti-cloud … comment qu’on fait ?
On rajoute la fin de support d’Office 2021 (dernière version à licence) pour octobre 2026 afin de pousser tout le monde sur Office365 (à abonnement). Que reste t’il avec une licence ? Windows 11 … ça sent bon le Windows 12 sans licence et fonctionnant sur abonnement Azure.
Et puis, on ajoute dans la réflexion le rapprochement de MS avec Apple et son business model … particulier.
En résumé, il reste un peu moins de 3 ans à ce jour pour mettre en œuvre une solution alternative permettant de faire tourner l’IT sans produit MS histoire de garder son autonomie en regard de la direction prise par MS.
#40
un temps il y avait une demo de Office365 en PWA.
https://www.youtube.com/watch?v=VNpoqUNMrh8&t=360s
#40.1
C’est toujours là, mais on parle simplement d’équivalents web aux apps desktop, et il n’y a jamais tout. Le problème ici, c’est la recommandation officielle de passer par la PWA, plutôt que de régler le problème de l’app desktop. Et comme ils encouragent les boites à y passer, ils ne comptent sans doute pas s’en occuper.
#40.2
Les versions web (de par leur nature synchrone) ne peuvent pas fournir un niveau d’interactivité avec les utilisateurs à l’image de ce que fait l’app desktop.
Et puis une app version web sous entend une connexion réseau permanente, rapide et réactive afin de ne pas plomber la productivité des utilisateurs.
#40.3
Je ne dis clairement pas le contraire :)
#40.4
Je vois … mais corrélé avec mon post sur la stratégie de MS sur les licences/abonnement + disparition des AD locales … on devine bien qu’ils ne vont pas investir dans un autre OS qui pourrait servir d’alternative aux personnes souhaitant quitter progressivement l’éco-système MS.
Mais bon, disons que ce sujet Teams vient conforter les autres éléments cités
#40.5
Les PWA peuvent avoir un système de stockage local, ce qui permet d’avoir une application stand-alone offline. Je ne sais pas ce qu’il en est de Team mais en tout cas c’est possible (après, est ce que c’est logique au vu du but de l’application).
Je n’ai pas compris ton histoire de “synchrone”. Fais-tu référence à ce qui se faisait avant javascript et surtout AJAX qui nécessitait de retélécharger une page à chaque modification ? La version web de MS Office est très réactive et n’a rien à envier à son équivalent bureau sur ce point. Et dans le cadre d’Electron qui possède techniquement un vue web (avec un serveur node.js), les applications Discord ou VScode n’ont aucun soucis de réactivité.
Je viens de jeter un oeil à la page “App showcase” d’Electron, et je vois qu’il y a Team dans la liste (des favorites qui plus est). Du coup, Team desktop ne serait-il pas déjà une application Electron ?
#41
Sinon, FreeIPA va plus loin que juste Samba et 386DS question fonctionnalités, et il ne se contente pas de la couche de compatibilité avec windows et propose aussi dns, pki, sudoers , HBAC, …
Si c’est pour faire des environnements mixtes Windows/Linux/Unix, c’est un gain de temps considérable. Par contre le troubleshooting est parfois plus ardu qu’une config plus minimaliste.
Reste qu’il est facile de l’intégrer à keycloack pour un SSO moderne
#41.1
Disons que des mecs capables de troubleshooter une brique composée de freeipa, samba, 389DS, MIT kerberos, dns, … doit pas y en avoir beaucoup en france.
Et dès mec qui connaissent et qu’en ont envie…
#42
Le point de départ est de ré-analyser ses besoins et de repartir sur des solutions simples et évolutives en mettant aux archives le poids du passé (tous ces trucs qui auraient dû être décommissionnés depuis des années).
#43
Je comprend bien ton point de vue.
Pour ma part j’ai toujours vu Electron comme un truc temporaire pour palier aux limitations du client web lorsqu’on y accède par le browser web normal/habituel. Bref un peu le même objectif que les ActiveX de l’époque.
Dés lors qu’on peut fournir 100% des fonctions via un browser web normal/habituel, je ne vois pas l’intérêt de electron. Quand bien même il est “techniquement possible” de faire une appli electron dans ce cas, je n’en vois pas l’utilité.
Et a mon avis Microsoft non plus n’en voit pas l’utilité. Dans leur monde rêvé à base de “Trusted Platform”, de “Microsoft account”, de “monthly subscription”, de “Online Store”… je ne vois pas bien où est leur intérêt de perpétuer le développement de logiciel lourd installé sur le disque-dur.
#43.1
L’intérêt se situe dans le déploiement, comme dit dans l’article. Il est très difficile de déployer une PWA sur un parc, particulièrement sur des systèmes où ladite PWA ne peut pas fonctionner avec le navigateur par défaut, Firefox dans la plupart des cas. La recommandation est donc d’installer un autre navigateur, de migrer les données, changer les habitudes pour avoir le droit d’utiliser une simple application web.
Une app Electron peut au moins être fournie en deb, rpm, snap ou autre, peut faire l’objet d’un déploiement centralisé et est indépendante du navigateur.
#44
Je ne suis pas étonné que Ms soit en low effort sur la gestion des parcs en Linux+FF.
Comme je le disais, ca ne rentre pas dans leur monde idéalisé de l’entreprise: des terminaux windows de confiance connectés 24⁄24 à microsoft.com sur une infra azure.
#45
On peut aussi renverser le problème.
Quelles sont les métriques de prise de décision pour décider d’investir sur une nouvelle plateforme ? Ici, le potentiel d’utilisateurs à atteindre, et les alternatives possibles.
Quel est le potentiel d’utilisateurs sous Linux uniquement ? Quel est le potentiel d’utilisateurs sous Linux refusant d’utiliser Chrome/Edge (qui sont ultra majoritaires en termes de navigateurs d’entreprise) ? Pourquoi MS devrait prendre à sa charge les développements pour une poignée d’irréductible qui n’est même pas à même de suivre les standards de leurs employeurs ? Quel serait le ROI ?
Surtout que bien souvent, ces postes Linux sont gérés par des jean-michel “mais moi je sais ce que je fais, moi môssieur mon linux je le compile à la main, pas comme vos windaubes là” totalement non gérés par l’IT, avec une couverture des patchs toute relative, ne répondant à aucun standard groupe, et qui constituent des enjeux en termes de sécurité et de continuité métier.
En alternatives purement MS, on peut avoir :
Bref, avant de sombrer dans le complotisme du “monde idéalisé”, on a aussi le droit de se poser les bonnes questions.
La disparition des AD locaux est une très bonne nouvelle, vu que presque aucune entreprise ne sait gérer ça correctement. L’AD est typiquement le genre de produit technique qui a impacté les métiers, au lieu de rester dans un rôle de support au métier. Et surtout, qui tombe comme une mouche à la première attaque sérieuse …
Encore une fois, est-ce le métier des entreprises de gérer une technologie aussi complexe avec ce que ça induit ?
Sinon, MS vend toujours des licences sans abonnements, si jamais.
Oui, en effet, c’est pour ça que la couche de sécurité (EDR par exemple) ne gère pas Android, mac/i OS, ni Linux en plus du monde MS. C’est aussi pour ça que M365 ne peut absolument pas s’exécuter sur autre chose qu’un Windows, et jamais sur du Mac. Les versions web qui ne dépendent pas des plateformes ? ça n’existe pas, la preuve, cette brève.
Ne parlons pas de la protection de l’IIoT/IoT, ça risque de faire mal aux éternels poncifs.
Quand on est dogmatique, tout vient conforter ses théories, c’est une certitude.
#46
Tu peux faire du glisser/déposer, stocker le contenu en local pour travailler dessus, émettre des alertes, faire tourner des process de scrutation ou de traitement en tâche de fond…
#47
J’utilise windows 11 avec un AD local, ça marche très bien. Et le support de WS 2022 termine en… 2031. On a encore un peu de temps devant nous.
Qui te dit qu’ils ne vont pas sortir une nouvelle version ?
#48
En réalité, le Jean-Mi bercé au clicodrome de Redmond depuis sa plus tendre enfance, c’est toi mon gars! Que de poncifs stupides. Au fait, d’un truc aussi précurseur qu’intelligemment conçu comme Skype, Microsoft en a fait quoi en le centralisant et niquant l’interface simple et efficace?
Renverser la dépendance? Bin voyons!
#49
Il n’y avait pas de complotisme dans mon commentaire. Ce que j’appelle le “monde idéalisé” c’est ce tu appelles le “potentiel d’utilisateurs à atteindre”, vu par Microsoft.
Si tu appelles un commercial Ms aujourd’hui en lui demandant ce qu’il propose pour gérer l’IT dans ton entreprise, il va te proposer ce que je décrivais plus-haut: des PC utilisés comme terminaux Windows (voir même virtualisés), des comptes microsoft.com et une infra azure.
#50
Ah oui, “ouga ouga moi vrai informaticien moi CLI moi pas souris”. Et on s’étonne ensuite que Linux n’ait jamais vraiment pris en entreprise :]
Un composant essentiel d’une offre entreprise adoptée par quasiment tout le monde ?
Une solution qui a sauvé des milliers d’entreprises pendant le confinement WW parce que personne n’était près ?
Forcer les techs à devoir écouter les besoins des utilisateurs et proposer des projets en adéquation avec, ainsi que toute la partie post-delivery (conduite du changement, formation …) ?
Oui, renverser la dépendance.
Si tu as besoin d’un outil qui n’est pas standard dans l’entreprise et que tu en es dépendant, avant de faire porter tout le poids de maintenir une nouvelle offre à la DSI, étudier les alternatives n’est pas interdit.
#51
#52
#53
#54
C’était en remarque à “l’insulte” d’habitué au clickodrome.
Et ça impacte potentiellement une personne, vs combien à la DSI pour devoir maintenir une nouvelle plateforme dans le temps ? Combien d’investissements pour quelques serveurs ? Du recrutement, du PRA, du management, de la mise à jour régulière, s’assurer de garder les compétences dans les équipes …
Tu remarqueras que j’ai parlé d’alternativeS, je n’ai jamais dit que WSL est la réponse à tout.
#55
#56
Rien compris. Tu veux faire du sigkill de tâches JS ?
Tu peux pas nous donner un exemple concret d’usage/application desktops impossible à reproduire en PWA ?
#56.1
Pour cela, il suffit de sortir des paradigmes java et de la cour des miracles que sont les librairies de ce langage. Il convient de savoir exploiter le matériel et l’OS en utilisant leur mécanismes internes. Le but du java est de cacher tout ça pour les reproduire (souvent mal) dans les JVM.
Exemple d’écran d’appli industrielle (et c’est que l’IHM, il ya aussi le mddle et back pour piloter les machines) :
https://www.thomas-mecanique.com/content/images/informatique-industrielle.v637026674780000000.jpg
#57
Ms reste très bon marché, malheureusement.
Je serais content de tout baser sur de l’alfresco, du jitsi, du onlyoffice et un stokage cloud nextcloud… Mais ça demanderait plus de compétence, de personnel, et le coût de maintenance serait très supérieur à Ms.
#58
Grand fou rire. Windows en lui-même est très bien sécurisé. Le problème de Windows avec les applis (de bureau), c’est effectivement un très lointain héritage de l’époque où l’on avait confiance dans le PC car il était en quasi vase clos. Mais c’est vraiment l’exception maintenant et depuis plusieurs longues années.
Franchement, le plus gros écart entre linux et windows, c’est le fait que sous linux un admin peut se faire passer pour n’importe quel utilisateur sans connaître son mot de passe, pas sous windows (il faut que l’admin modifie le mot de passe). A part cela, ils sont équivalents en terme de sécurité niveau noyau
La plupart des clients légers que j’ai déployés sont sur un principe d’écran déporté: soit en telnet/ssh, soit en VNC, soit en RDP ou citrix.
Et j’en ai déployé en industriel (RDP sur des terminaux mobiles en Wifi type “scanner” avec écran en 320x240). C’est impécable.
Et j’ai l’impression que tu mélange (a)synchrone et connecté. Le HTML n’est justement pas un système connecté: chaque requête ignore la précédente. Ce qui n’est pas le cas de protocoles type VT/RDP/X
Quand à la capacité d’un client léger à gérer le temps réel - vu qu’on faisait tu temps réel sur des terminaux à 1MHz, je pense qu’on peut toujours le faire - mais il faut savoir ce que temps réel veut dire, et comment se donner les moyens que ça fonctionne.
#58.1
Sécurité Windows : Quand tu es passé sur le SDK16, puis le SDK32, puis sur les MFC et enfin le .NET, ben nan, la sécurité Windows est moisie. Les vieux problèmes sont masqués mais pas corrigés.
Va voir par toi même, tu vas être surpris.
Info Industrielle : déployer des scanners de code EAN sur des tablettes ça n’a rien à voir avec le pilotage par commandes numériques de robots sur des chaînes de production et autres installation lourdes. On ne parle pas de la même informatique là.
#59
Non. Même Windows, ça se gère en ligne de commande, sinon c’est une perte de temps phénoménale.
Ca je suis à peu près d’accord, mais c’est pas WSL, c’est le problème de passer d’un Linux à l’autre sans se soucier des dépendances -> il faut toujours maîtriser ses dépendances ou se coller à un standard type flatpack.
#60
Ah? C’est ballot, là ou je suis tout le vrai travail (productif, s’entend, de développement de nos produits) se fait sous Linux.
Certes, les laptops désormais généralisés sont windows car le côté utilisateurs des parcs est administré par des gens qui ne connaissent que cela (et des prestataires externes allant au plus commun) et que pour la bureautique/mal/chat tout le monde prends le tout cuit de Microsoft. Mais je peut te dire que 90% de leur usage est de faire terminal X (via un cygwin/X, une VM complète, parfois WSL désormais pour ceux qui ont confiance) pour se connecter aux VM de dev en cloud qui ont remplacées les PC fixes sous chaque bureau… qui étaient alors de base sous Linux et avec une VM windows (situation inverse des laptops actuels!) pour la bureautique (même si pas mal utilisaient en fait open/libre-office côté Linux, plus simple pour écrire la doc avec le source à côté et n’utilisaient word que pour passer les macros du système de gestion de doc car les documentalistes n’avaient appris que ce truc basé VB)… qui avaient elles mêmes remplacé les 2 machines que chaque ingé en R&D avait il y a 20 ans sous son bureau (la stagiaire était alors bien chauffée!): Une station SUN pour le boulot sérieux (avec déjà l’ancêtre Star-Office qui pointait son nez) et un PC windows pour la bureautique.
Essentiel? Teams est arrivé en retard (mais les machins Cisco n’étaient pas meilleurs et les solutions utilisateurs, pb de droit, souvent limitées à ce qui tournait dans le navigateur) si tu te souviens bien même si MS a sauté qqmois après sur l’occase pour pousser à fond ce truc si mal branlé que certains ne l’allument plus sauf à le leur demander… par mail!
Va retrouver une info collée dans un fil des mois après la dedans vu le foutoir. Niveau mail, aucun pb: Des trucs vieux de plusieurs mois/années retrouvés en 5mn ont parfois sauvé mon cul. Et pas qu’a moi, cf IBM/SCO et une antériorité salvatrice de prouvée sur une sombre histoire de brevet. Même pas certain que les obligations légales de conservation s’appliquent à la messagerie instantanée d’ailleurs.
Teams, en réalité, tout le monde s’en plaint autour de moi et avec le TL qui a pris un coup d’accélérateur, est plus vécu comme un mal obligé.
Des standards de chat/VoIP/Visio, c’est pas ce qui manque, utilisables avec le choix de son applicatif.
Cela peut ne pas être le cas, tel Skype (construit avec la résilience et usage des ressources optimisé du fait de son fonctionnement P2P), car il n’est pas interdit d’innover/d’être pionnier. Mais MS l’a tué avec ses innovations avec en le rachetant puis le centralisant (plus facile pour satisfaire la NSA?).
Un standard, c’est pas celui qui est poussé par une boite voulant asseoir sa domination aux dépends du reste. Sinon on en revient à la situation Internet Exploder…
#61
Cela a progressé, mais il ne faut pas nier qu’un système parti mono-utilisateur et donc sans besoin d’une gestion des droits day 1… puis construit sur une compatibilité ascendante et binaire… eh bien il aura toujours des trous.
Les Unices étaient multi-utilisateurs (+tâches) plus de 10 ans avant le 1er PC. Et déjà traversés par la stack réseau. Tout ce qui n’est arrivé chez Microsoft que sous forme de surcouche malpropre avec windows 3.11 (for workgroups) encore plus de 10 ans après.
Soit un truc de cochon avec plus de 20 ans de retard! Et qui pèse toujours sur les versions actuelles.
#62
Non pas de windows server sur les postes de travail.
Et ça m’étonnerais qu’on soit réellement obligé d’utiliser AAD/compte MS tant que server 2022 sera supporté. MS impose déjà le compte en ligne pour la pro sur la 22H2 mais les contournements existent. S’ils retirent la possibilité de bypass, ça risque de gueuler très fort.
Sinon il reste toujours la entreprise (voir la LTSC), qui permet de créer un compte local sans bidouille.
Ah, je cherchais justement l’info, t’aurais un lien ?
#62.1
Pour office, je viens de voir qu’il existe la version LTSC pour les entreprises (je l’avais vu passer mais je m’en souvenais plus), qui est donc perpétuelle. Par contre pas d’autre version GP après la 2021.
Et il a bien été confirmé d’autres versions LTSC à l’avenir.
FAQ sur Office 2021 et Office LTSC pour Windows et Mac
#63
Si on parle au niveau du noyau, je dirais non. Quand à l’historique Windows 3.11, il n’y a pas grand chose de commun entre le noyau NT actuel et le Windows 3.11 de l’époque (déjà pas un NT, et effectivement avec une stack ajoutée rapidement).
On n’est plus à l’époque de Windows 95 et de loin.
La partie réseau actuelle hérite de celle de XP, mais surtout de celle de Vista.
Quand à la sécurité de Linux et des unix, elle dépend, comme celle de Windows, des bonnes pratiques des utilisateurs et des programmes.
Exemple: l’affichage graphique. Linux a commencé avec un serveur X “classique”: serveur en utilisateur privilégié et client sous le login utilisateur, et communication via la couche réseau. Ensuite pour satisfaire aux besoins de 3D et parce que c’était plus simple, on a permis d’afficher dans le client des éléments fournis sous le login root.
Maintenant on abandonne carrément la partie X pour mimer ce que Windows fait - avec tous les risques de sécu qui arrivent si quelqu’un fait une erreur dans un programme…
X avait une architecture sécurisée. Wayland, je ne trouve pas.
#64
MFC et .Net n’avaient pas à corriger la sécu. Les vieux problèmes ont été corrigés, ou alors cite un exemple concret.
Exemple de correction: sous Win95, on pouvait lister les fenêtres et ajouter un timer dessus, qui déclenchait une routine définie avec les droits du process parent de la fenêtre. Il n’y avait pas de vérification des droits -> on pouvait utiliser l’icône de l’antivirus pour déclencher sa routine avec les droits de l’antivirus.
On ne peut plus depuis Windows 2000.
Autre exemple: sous Windows, seul un utilisateur peut modifier son fond d’écran, son de démarrage ou son imprimante par défaut (sauf GPO). Même si tu es administrateur du poste, tu ne pourras pas passer outre.
Je peux te citer plusieurs “légendes urbaines” sur l’informatique (et le plus souvent windows), qui ont été résolues il y a 20 ans (comme le fait de cliquer sur “éjecter” avant de retirer une clé USB)…
C’est assez navrant de voir que les gens ne se mettent pas à jour, et continuent de comparer Windows en tant qu’OS et DE, et Linux uniquement niveau noyau. Si on compare Windows et Linux, autant comparer Windows Server Core et Linux server, ce sera plus proche.
(au fait, je ne défends pas la qualité des outils Microsoft en ligne: O365 et sharepoint, onedrive, teams sont bourrés de bugs, problèmes navrants et autres incongruités ou irritants - mais par contre, ce sont les moins chers du marché … et ayant administré du Windows, je dois avouer que c’est un OS sérieux, très bien documenté et transparent, là où pour Linux ça dépend de la distro et la doc est très en-deça pour beaucoup de parties)
#64.1
Je vois … tu gères au travers des docs et de l’actualité.
Le coup de la clé USB, « l’éjection » sert à flusher le cache disque afin d’éviter une corruption du FS de la clé. Mais bon … cela fait partie des exercices pratiques que je prodigue à mes gamins afin de leur apprendre à utiliser efficacement l’outil informatique.
#65
Je n’ai pas dit le contraire, même si je serais quand même pas surpris que du code de l’époque voir avant soit encore présent. Le crédo de la compatibilité ascendante au niveau binaire ne peut que favoriser ce genre de choses. Mais bon, c’est pas de l’open-source alors pas possible d’en avoir le coeur net. Et ce constat sur l’applicatif vaut aussi en partie pour le support matériel: Les driver-model Linux évoluent et tout ce qui est remonté upstream suit ces évolutions. Windows, avec des partenaires dans le même modèle de fourniture de binaires sur sources fermés, je pense qu’il faut qu’il n’y ait vraiment pas le choix pour que cela bouge vue la masse à bouger derrière, qui ne va pas manquer de râler pour suivre… ou lâcher le support, mais dans ce cas c’est les utilisateurs qui râlent!
Le pb de Wayland, pour moi, c’est au delà de la sécurité comparée que je ne saurais évaluer: J’utilise énormément le X11 forwarding via ssh.
Les développeurs de Wayland ayant dit ouvertement qu’ils n’en avaient rien à cirer d’un usage à travers le réseau, j’avoue que j’ai arrêté de regarder un projet qui est une régression majeure pour cet usage je crois assez commun.
Même des machines installées headless (genre le raspberry qui gère la baraque), sur lesquelles aucun environnement de bureau n’est installé ni même le support matériel GPU s’il y en a un (minimisant conso/chauffe)… eh bien j’aime bien pouvoir y coller un support X minimal frame-buffer via xvfb: Cela me permet d’installer quelques outils graphiques simples (en évitant tout ce qui va tirer quasiment un Gnome ou un KDE complet) et légers (éditeur type nedit ; rxvt-unicode en terminal…) afin de travailler avec un peu plus de confort en graphique à travers le réseau.
#66
#66.1
Je ne m’inquiète pas sur le fait qu’il y aura toujours des petits malins pour contourner le système.
Curieux de voir comment ça va évoluer. En tout cas si on en arrive réellement à ne plus pourvoir s’en servir sans compte, ce sera un adieu définitif. J’ai déjà tout ce que qu’il faut sous Linux.
#67
Certes, mais cela ne fait que garantir que le boulot est fait côte OS. Pour ce qui est de savoir si derrière le contrôleur de la clef (une machine à lire/écrire des LBA, comme un bon vieux HDD, bien loin de la complexe gestion d’une mémoire flash) c’est effectivement arrivé dans la flash, mieux vaut ne pas l’extraire dans les qq centaines de ms qui suivent tout de même!
Puis je ne sais pas sous Windows, mais côté Linux on ne manque pas de réglages côté gestion de la mémoire virtuelle pour régler la bufferisation (plutôt qu’un cache, qui est en général une mémoire dédiée), les délais de commit… tout ceci afin de pouvoir mieux gérer les regroupements d’écritures etc…
Par exemple, ce simple changement sur un Raspberry PI tournant 24⁄7 à gérer la barraque et sur batterie tampon (donc jamais de coupure de courant, permettant de mettre des temps de commit de 120s donc >> 5s par défaut, de mémoire), niveau /etc/sysctl.conf, me permet d’éviter de rincer les cartes SD si on laisse les logs dessus (on peut les mettre aussi dans un tmpfs en ram mais sur reboot c’est perdu):
vm.dirty_ratio=60
vm.dirty_expire_centisecs=120000
On peut aussi régler/tester en live via le sysfs avant de mettre cela dans le sysctl pour que cela persiste.
Simple et efficace, aussi au bénéfice des perfs: Plus jamais de lag de l’interface web de Domoticz par exemple…
A l’inverse on pourrait avoir une gestion plus aggressive de la bufferisation. Par contre pas certain qu’on puisse la limiter aux stockages extractibles (réglage global ici).
#68
Ca date de Windows 98/Windows 2000. A l’époque, Windows n’avait pas de gestion différente des disques amovibles et fixes (sauf les disquettes, mais elles n’étaient considérées comme des disques) et le support USB était nouveau. Pour rappel, une clé USB a un protocole proche des disques SCSI. Donc on passait par la partie de gestion des disques dur pour les clés USB, sans hotplug.
Par défaut, l’écriture sur les disques durs était différée pour améliorer les perfs…
Jusqu’à Windows XP, qui a désactivé PAR DEFAUT l’écriture différée sur les clés et disques amovibles!
Donc ce n’est plus d’actualité depuis 2001⁄2002 environ … 20 ans de retard, comme les remarques sur la sécu….
Ca c’est au matériel de ne pas mentir. Quand on active le cache d’écriture, l’OS n’attend pas l’écriture et répond au programme “c’est fait”.
Quand on le désactive, l’OS attend que le matériel lui dise “c’est fait” pour le dire au programme.
Il y a 3 cas:
Bien vu! Sous Windows on en a rarement le besoin car on l’utilise peu depuis une carte SD. Il y a aussi des paramètres.