Connexion
Abonnez-vous

La PWA de Teams est « officiellement » disponible pour Linux, un cadeau empoisonné

La PWA de Teams est « officiellement » disponible pour Linux, un cadeau empoisonné

Le 09 novembre 2022 à 06h15

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.

Le 09 novembre 2022 à 06h15

Commentaires (106)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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 :/

votre avatar

compatible qu’avec Chrome et Edge


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 :)

votre avatar

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.

votre avatar

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

votre avatar

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 :D

votre avatar

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 :transpi:

votre avatar

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).

votre avatar

“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…

votre avatar

Ç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 :transpi:

votre avatar

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/

votre avatar

fofo9012 a dit:


pour installer edge ou chrome faut aller bricoler la source list :)


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.

votre avatar

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…

votre avatar

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 !

votre avatar

yl a dit:


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.



Nan mais ça c’est le full feature, tu as la même expérience que sous windows
:troll:


votre avatar

pamputt a dit:


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 :D


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 🙂

votre avatar

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 ^^

votre avatar

Okki a dit:


Ils sont également dispos sur Flathub


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.

votre avatar

girafe_t a dit:


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/


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.

votre avatar

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:




Microsoft sait parfaitement manier Electron, comme elle l’a très bien montré avec Visual Studio Code.


C’est ironique non ? :transpi:

votre avatar

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.

votre avatar

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 ?

votre avatar

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).

votre avatar

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.

votre avatar

yl a dit:


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.


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.

votre avatar

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.

votre avatar

Okki a dit:


Ils sont également dispos sur Flathub (Chrome / Edge).



Flathub c’est aussi très Windowesque dans la philosophie.


votre avatar

girafe_t a dit:


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/


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.

votre avatar

yl a dit:


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.


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.

votre avatar

pamputt a dit:


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.


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.

votre avatar

pamputt a dit:


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.


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.

votre avatar

ragoutoutou a dit:


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.


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 23 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”…

votre avatar

Winderly a dit:


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.


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.

votre avatar

pamputt a dit:


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.


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)

votre avatar

jpaul a dit:


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.


Si la boite utilise Teams et à des postes Linux, c’est qu’elle a eu une erreur de raisonnement à un moment.

votre avatar

Ah bon ?



Elle peut avoir une majorité de postes souis Windows et certains sous Linux.

votre avatar

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 23 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.

votre avatar

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 : lefigaro.fr Le Figaro

votre avatar

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)

votre avatar

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.

votre avatar

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).

votre avatar

pamputt a dit:


Si la boite utilise Teams et à des postes Linux, c’est qu’elle a eu une erreur de raisonnement à un moment.


Teams peut être imposé par un gros client sur un projet spécifique.

votre avatar

Okki a dit:


Non, les distributions ne savent pas faire.


Bin tiens!




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.


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.




Linux est à des années lumière de la compatibilité descendante d’un Windows.


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…




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


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.

votre avatar

fred42 a dit:


Ah bon ?



Elle peut avoir une majorité de postes souis Windows et certains sous Linux.


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.

votre avatar

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.

votre avatar

“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.

votre avatar

pamputt a dit:


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.


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.

votre avatar

tazvld a dit:


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.


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.

votre avatar

SI c’est pour avoir à la place une appli à base d’Electron, autant avoir une PWA qui utilise le navigateur déjà installé.

votre avatar

Le_CuLtO a dit:


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…


Ah c’était pas que moi alors

votre avatar

DemonCanard a dit:


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.


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. :transpi:

votre avatar

tazvld a dit:


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.


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
github.com GitHub

votre avatar

yl a dit:


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.



Entres autres mais pas que…



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 23 de chances de planter toute l’interface graphique et devoir faire ctrl/alt/f1+login console, killall vnc, ctrl/alt/f7.


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.




Pour le truc qui “dépanne”, franchement, je dirais plutôt que le concept vicié de base tombe plutôt “en panne”…


J’utilise souvent flatpack, parfois appimage et j’ai peu de soucis avec eux, moi ça me dépanne.

votre avatar

yl a dit:


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.


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.

votre avatar

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.


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.

votre avatar

Tu as d’autres exemples que Teams pour Linux ?

votre avatar

pamputt a dit:


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.


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.




D’une part ça coûtera plus cher à long terme


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”.




et d’autre part, les données sensibles (commerciales ou autre) sont gentiment envoyés à l’étranger.


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.

votre avatar

pamputt a dit:


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 : lefigaro.fr Le Figaro


J’attends de voir le bazar que sera de ne pas mettre ses oeufs dans le même panier:




  • Payer un presta pour le maintien de l’OS

  • Payer un autre pour le support Libre office

  • Payer un troisième pour le support de la visio

  • Payer un autre pour l’identifiant unique/SSO

  • Payer l’hébergement des documents + sauvegarde
    … Payer les formations à tout le monde …

votre avatar

Myifee a dit:


Pareil, Air France fait ses propres avions ?


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.

votre avatar

Wosgien a dit:


J’attends de voir le bazar que sera de ne pas mettre ses oeufs dans le même panier:




  • Payer un presta pour le maintien de l’OS

  • Payer un autre pour le support Libre office

  • Payer un troisième pour le support de la visio

  • Payer un autre pour l’identifiant unique/SSO

  • Payer l’hébergement des documents + sauvegarde … Payer les formations à tout le monde …


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….)

votre avatar

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…

votre avatar

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.

votre avatar

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.

votre avatar

fofo9012 a dit:


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 :)


Nan nan, tu peux trouver les versions stables … qui mettent à jour toutes seules la liste des dépôts apt :8

votre avatar

yl a dit:


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.


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.




fred42 a dit:


SI c’est pour avoir à la place une appli à base d’Electron, autant avoir une PWA qui utilise le navigateur déjà installé.


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.

votre avatar

pamputt a dit:


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 : lefigaro.fr Le Figaro


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.

votre avatar

Vincent_H a dit:


Tu as d’autres exemples que Teams pour Linux ?


un temps il y avait une demo de Office365 en PWA.



youtube.com YouTube

votre avatar

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.

votre avatar

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.

votre avatar

Je ne dis clairement pas le contraire :)

votre avatar

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 :fou:

votre avatar

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 ?

votre avatar

aureus a dit:



SSO à l’ancienne = kerberos => fait partie d’un stack AD standard


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

votre avatar

:D
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…

votre avatar

Myifee a dit:


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” ?



Vue la torpeur et les profils « exploitants » qu’on a aujourd’hui dans les DSI, ça va être douloureux … mais salutaire.


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).

votre avatar

Vincent_H a dit:


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.


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.

votre avatar

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.

votre avatar

Vincent_H a dit:


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.


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 2424 à microsoft.com sur une infra azure.

votre avatar

(quote:2104089:127.0.0.1)
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 2424 à microsoft.com sur une infra azure.


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 :




  • Un poste W365 / AVD accessible via le poste Linux

  • Un poste Windows, qui consomme du Linux via WSL, pour renverser la dépendance

  • Un poste secondaire (comme vu dans pas mal d’entreprises) pour les populations tech

  • En cas d’entreprise radine, un téléphone portable



Bref, avant de sombrer dans le complotisme du “monde idéalisé”, on a aussi le droit de se poser les bonnes questions.




TNZfr a dit:


Je vois … mais corrélé avec mon post sur la stratégie de MS sur les licences/abonnement + disparition des AD locales …


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.




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.


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.




Mais bon, disons que ce sujet Teams vient conforter les autres éléments cités :fou:


Quand on est dogmatique, tout vient conforter ses théories, c’est une certitude.

votre avatar

TNZfr a dit:


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.


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…

votre avatar

TNZfr a dit:


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).


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.




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.


Qui te dit qu’ils ne vont pas sortir une nouvelle version ?

votre avatar

Myifee a dit:


On peut aussi renverser le problème.
(…)
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…


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?




En alternatives purement MS, on peut avoir :




  • Un poste W365 / AVD accessible via le poste Linux

  • Un poste Windows, qui consomme du Linux via WSL, pour renverser la dépendance


Renverser la dépendance? Bin voyons!

votre avatar

Myifee a dit:


Bref, avant de sombrer dans le complotisme du “monde idéalisé”, on a aussi le droit de se poser les bonnes questions.


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.

votre avatar

yl a dit:


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.


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 :]




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?


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 …) ?





  • Un poste Windows, qui consomme du Linux via WSL, pour renverser la dépendance



Renverser la dépendance? Bin voyons!


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.

votre avatar

Myifee a dit:


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 ?



En dehors du fait que les AD sont généralement confiées à des 2-mains-gauches-et-10-pouces pour des raisons de masse salariale bien souvent, leur disparition du SI pose un gros problème stratégique. Ce n’est plus une opération technique en soi, tous les métiers de la boîte sont touchés jusqu’au conseil d’administration (pilote de la stratégie) … et là, ce n’est plus du tout la même limonade. La priorité n’est plus de faire fonctionner mais de protéger la confidentialité.
La mise en lumière du problème Azure AD avec Windows 11 auprès d’un DRH a provoqué une réaction de panique immédiate … donc bon, même les non-techniques identifient le risque rapidement.



Sinon, MS vend toujours des licences sans abonnements, si jamais.



Pour l’instant …. on verra en 2026 avec la fin de support d’Office 2021.



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.



Je rebondis pour la partie Linux : les couches de sécurité sont beaucoup plus efficientes sur un Linux que sur Windows. La sécurité est hard-codée dans le noyau Unix de base … dans Windows, les premières briques d’identification sont arrivées avec Windows 3.11 for workgroups. Elles ont évoluées au fil des versions DOS et ont été conservées sur les versions NT. En gros, dans les noyaux NT tu vas trouver des mécanismes de sécurité issus d’Unix ET d’OpenVMS. Mais ces derniers ne sont que très peu utilisés en raison de l’approche applicative héritée des versions DOS. Pour cette raison, Windows aura toujours un train de retard sur la sécurité et il faudra toujours sortir une armée mexicaine d’outils tiers pour gérer presque proprement les trous laissés par MS.



Ne parlons pas de la protection de l’IIoT/IoT, ça risque de faire mal aux éternels poncifs.



Le problème de l’IoT, c’est le patch management … et la durée (ridicule) du support applicatif et système.



Quand on est dogmatique, tout vient conforter ses théories, c’est une certitude.



Le dogmatisme consiste à regarder le tableau d’ensemble et à réfléchir 1 minute ? … dans ce cas je suis dogmatique.



v1nce a dit:


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…



Oui … sur base de fonctions applicatives qui singent des mécanismes système de base en moins performant et moins autonome. Redévelopper l’existant à chaque application est le piège de débutant. Là, en raison du contexte connecté + navigateur synchrone, il est complexe de copier des fonctionnalités d’applications locales (client lourd) basées sur des mécanismes système ET pouvant fonctionner sans connexion.



tazvld a dit:


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).



De par la fonction principale de Teams, si tu retires le réseau … tu ne vas pas bien loin.



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é.



Les clients légers sont basés sur l’utilisation d’un navigateur internet en html … ce protocole applicatif est synchrone (1 question, 1 réponse et c’est tout). Les interactions homme-machine ne sont pas forcément synchrones, elles sont souvent asynchrones (1 question/action, plein de réponses avec une temporalité éparse).
Hors, de base, la logique client léger n’a pas été conçue pour l’asynchrone. Ce mode de fonctionnement est arrivé au travers des exemples que tu as cité mais avec beaucoup de limitations. Les applications industrielles ne sont pas en client léger, la gestion de l’évènementiel / temps réel exige une réactivité et une fiabilité que les clients légers (même techniquement détournés) ne peuvent fournir.
(dans les mécanismes système recréés, les interruptions logicielles par exemple sont toujours absentes : signaux Unix, AST OpenVMS … )


votre avatar

renaud07 a dit:


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.



Tu mets des Windows Server sur les postes de travail ?
Les grands comptes ont depuis longtemps dégagé les WS non essentiels des datacenters en raison du coûts RH qu’ils représentaient.



Qui te dit qu’ils ne vont pas sortir une nouvelle version ?



Microsoft eux même … on ne peut pas faire plus précis comme source.


votre avatar

Myifee a dit:


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 :]



Ben , je t’invite à refaire une passe sur ce qu’il se fait aujourd’hui, Un linux se gère tout à la souris … même par des non techniciens.



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.



Pour le WSL, essaie le, mesures en la productivité, le temps passé à le configurer … ainsi que le temps passé à ré-ajuster ton application lors des 1ers tests sur serveur Linux. Et après on cause.


votre avatar

TNZfr a dit:


Ben , je t’invite à refaire une passe sur ce qu’il se fait aujourd’hui, Un linux se gère tout à la souris … même par des non techniciens.


C’était en remarque à “l’insulte” d’habitué au clickodrome.




Pour le WSL, essaie le, mesures en la productivité, le temps passé à le configurer … ainsi que le temps passé à ré-ajuster ton application lors des 1ers tests sur serveur Linux. Et après on cause.


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.

votre avatar

Myifee a dit:


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.



Certes, mais aujourd’hui ce n’est plus une personne dans un coin … c’est quasiment toutes les équipes de DEV qui doivent manipuler du docker/kubernetes. Et ça commence à faire du monde.
A cela tu ajoutes cet « alignement de planète » que MS nous prépare et l’obligation de réfléchir à des alternatives (à tous niveaux) est présente.


votre avatar

TNZfr a dit:


Les clients légers sont basés sur l’utilisation d’un navigateur internet en html … ce protocole applicatif est synchrone (1 question, 1 réponse et c’est tout). Les interactions homme-machine ne sont pas forcément synchrones, elles sont souvent asynchrones (1 question/action, plein de réponses avec une temporalité éparse). Hors, de base, la logique client léger n’a pas été conçue pour l’asynchrone. Ce mode de fonctionnement est arrivé au travers des exemples que tu as cité mais avec beaucoup de limitations. Les applications industrielles ne sont pas en client léger, la gestion de l’évènementiel / temps réel exige une réactivité et une fiabilité que les clients légers (même techniquement détournés) ne peuvent fournir. (dans les mécanismes système recréés, les interruptions logicielles par exemple sont toujours absentes : signaux Unix, AST OpenVMS … )


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 ?

votre avatar

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

votre avatar

ragoutoutou a dit:


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,


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.

votre avatar

TNZfr a dit:


Je rebondis pour la partie Linux : les couches de sécurité sont beaucoup plus efficientes sur un Linux que sur Windows. La sécurité est hard-codée dans le noyau Unix de base … dans Windows, les premières briques d’identification sont arrivées avec Windows 3.11 for workgroups. Elles ont évoluées au fil des versions DOS et ont été conservées sur les versions NT. En gros, dans les noyaux NT tu vas trouver des mécanismes de sécurité issus d’Unix ET d’OpenVMS. Mais ces derniers ne sont que très peu utilisés en raison de l’approche applicative héritée des versions DOS.


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




Les clients légers sont basés sur l’utilisation d’un navigateur internet en html … Les applications industrielles ne sont pas en client léger, la gestion de l’évènementiel / temps réel exige une réactivité et une fiabilité que les clients légers (même techniquement détournés) ne peuvent fournir. (dans les mécanismes système recréés, les interruptions logicielles par exemple sont toujours absentes : signaux Unix, AST OpenVMS … )


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.

votre avatar

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à.

votre avatar

TNZfr a dit:


Ben , je t’invite à refaire une passe sur ce qu’il se fait aujourd’hui, Un linux se gère tout à la souris … même par des non techniciens.


Non. Même Windows, ça se gère en ligne de commande, sinon c’est une perte de temps phénoménale.




Pour le WSL, essaie le, mesures en la productivité, le temps passé à le configurer … ainsi que le temps passé à ré-ajuster ton application lors des 1ers tests sur serveur Linux. Et après on cause.


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.

votre avatar

Myifee a dit:


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 :]


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.




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 …) ?


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é.




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.


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…

votre avatar

Wosgien a dit:


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.


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.

votre avatar

TNZfr a dit:


Tu mets des Windows Server sur les postes de travail ? Les grands comptes ont depuis longtemps dégagé les WS non essentiels des datacenters en raison du coûts RH qu’ils représentaient.


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.




Microsoft eux même … on ne peut pas faire plus précis comme source.


Ah, je cherchais justement l’info, t’aurais un lien ?

votre avatar

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

votre avatar

yl a dit:


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.


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.




Soit un truc de cochon avec plus de 20 ans de retard! Et qui pèse toujours sur les versions actuelles.


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.

votre avatar

TNZfr a dit:


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.


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)

votre avatar

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.

votre avatar

Wosgien a dit:


On n’est plus à l’époque de Windows 95 et de loin.


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!




X avait une architecture sécurisée. Wayland, je ne trouve pas.


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.

votre avatar

renaud07 a dit:


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.



Ben MS s’en doute, c’est bien pour ça qu’ils n’en parlent pas trop. Ils doivent espérer qu’en mettant tout le monde devant l’mur sans sommation ça devrait passer.
Les contournements permettent de continuer à fonctionner, mais sans prise en charge MS officielle, il faut s’attendre à des pétouilles qui finiront par devenir bloquantes au fil des mises à jour système.


votre avatar

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.

votre avatar

TNZfr a dit:


Le coup de la clé USB, « l’éjection » sert à flusher le cache disque afin d’éviter une corruption du FS de la clé.


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 247 à 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).

votre avatar

TNZfr a dit:


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 20012002 environ … 20 ans de retard, comme les remarques sur la sécu….




yl a dit:


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!


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:




  • Le matériel est bien fait et synchrone: on sait que c’est fait

  • Le matériel est mal fait et répond au hasard: il faut le jeter

  • Le matériel est ultra bien fait et gère son propre cache (carte de serveur avec mémoire+pile intégrée, SSD avec un cache SLC ou RAM + condo en cas de coupure): le matériel garanti quand même qu’une relecture va donner la “bonne” donnée, même si elle n’est pas encore physiquement sur le disque.




Par exemple, ce simple changement sur un Raspberry PI tournant 247 à 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


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.

La PWA de Teams est « officiellement » disponible pour Linux, un cadeau empoisonné

Fermer