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

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

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

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)


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



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


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


Vincent_H

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


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


pamputt

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


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:


pamputt

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


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


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


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


Kazer2.0

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


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/



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.


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



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:




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 🙂


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



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.



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.


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:


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.


tazvld

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.


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 ?


eglyn

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 ?


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


tazvld

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


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.



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.


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.



Okki a dit:


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



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




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.



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.



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.



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.



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



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.



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)



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.


Ah bon ?



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


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.


jpaul

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.


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


pamputt

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


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)


Myifee

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)


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.


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



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.



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.



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.


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.


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



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.



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.


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



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



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:



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
https://github.com/filips123/PWAsForFirefox



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.



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.



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.


Tu as d’autres exemples que Teams pour Linux ?



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.



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 : https://www.lefigaro.fr/secteur/high-tech/le-non-de-collectivites-locales-a-microsoft-20221012




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 …



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.



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


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…


aureus

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…


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.


ragoutoutou

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.


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.



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



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.



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 : https://www.lefigaro.fr/secteur/high-tech/le-non-de-collectivites-locales-a-microsoft-20221012




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.



Vincent_H a dit:


Tu as d’autres exemples que Teams pour Linux ?




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



https://www.youtube.com/watch?v=VNpoqUNMrh8&t=360s


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.


Vincent_H

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.


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.


TNZfr

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.


Je ne dis clairement pas le contraire :)


Vincent_H

Je ne dis clairement pas le contraire :)


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:


TNZfr

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.


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 ?



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


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



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



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.


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.



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.



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



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…



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 ?



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!



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.



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.



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




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.




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.




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.



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.




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 ?


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